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Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 



Introduction 



Electronic commerce is emerging as the future way of doing business between companies across local, wide area and 
global networks. Trust in this way of doing business is essential for the success and continued development of 
electronic commerce. It is therefore important that companies using this electronic means of doing business have 
suitable security controls and mechanisms in place to protect their transactions and to ensure trust and confidence with 
their business partners. In this respect the electronic signature is an important security component that can be used to 
protect information and provide trust in electronic business. 

The European Directive on a community framework for Electronic Signatures (also denoted as "the Directive" or the 
"European Directive" in the rest of the present document) defines an electronic signature as: "data in electronic form 
which is attached to or logically associated with other electronic data and which serves as a method of authentication". 

The present document is intended to cover electronic signatures for various types of transactions, including business 
transactions (e.g. purchase requisition, contract, and invoice applications). Thus the present document can be used for 
any transaction between an individual and a company, between two companies, between an individual and a 
governmental body, etc. The present document is independent of ny environment. It can be applied to any environment 
e.g. smart cards, GSM SIM cards, special programs for electronic signatures, etc. 

The ETSI standard TS 101 733 [1] defines formats for advanced electronic signatures that remain valid over long 
periods, are compliant with the European Directive and incorporate additional useful information in common use cases 
(like indication of the commitment got by the signature production). Currently, it uses Abstract Syntax Notation 1 
(ASN.l) and is based on the structure defined in RFC 3369 [2] (in the present document the signatures aligned with this 
RFC will be denoted as CMS signatures). 

TS 101 733 [1]: 

• Defines new ASN. 1 types able to contain information for qualifying the CMS signatures so that they fulfil the 
aforementioned requirements. 

• Specifies how this qualifying information must be incorporated to the CMS signatures. 
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Currently, the IETF W3C XML-Signature Working Group has developed a syntax for XML signatures: 
"XML-Signature Core Syntax and Processing" [3] (denoted as XMLDSIG in the present document). This syntax 
provides a basic functionality for digitally signing several data objects at the same time. It also provides basic means to 
incorporate any kind of needed qualifying information. 

The present document: 

• specifies XML schema ( [5]) definitions for new XML types that can be used to generate properties that 
further qualify XMLDSIG signatures with information able to fulfil a number of common requirements such 
as the long term validity of the signature by usage of time-stamps, etc. 

• defines mechanisms for incorporating the aforementioned qualifying information; 

• specifies formats for XML advanced electronic signatures that, by using the specified new XML types, remain 
valid over long periods and incorporate additional useful information in common use cases. These signatures 
will be built on XMLDSIG by addition of these properties as specified in [3], using the ds : Ob j ect XML 
element defined there (here, as for the rest of the document, ds has been used as the prefix denoting the 
namespace defined in [3]. Its value is defined in clause 4); 

• defines a set of conformance requirements to claim endorsement to the present document. 

The present document specifies two main types of properties: signed properties and unsigned properties. The first ones 
are additional data objects that are also secured by the signature produced by the signer on the ds : Signedinf o 
element, which implies that the signer gets these data objects, computes a hash for all of them and generates the 
corresponding ds : Reference element. The unsigned properties are data objects added by the signer, by the verifier 
or by other parties after the production of the signature. They are not secured by the signature in the ds : Signature 
element (the one computed by the signer); however they can be actually signed by other parties (time-stamps, 
countersignatures, certificates and CRLs are also signed data objects). 

The XML advanced electronic signatures defined in the present document will be built by incorporating to the XML 
signatures as defined in [3] XMLDSIG one new ds : Ob ject XML element containing the additional qualifying 
information. 



Editorial conventions 

As it has been anticipated in the former clause, throughout the rest of the document the term XMLDSIG will refer to 
XML signatures with basic functionality, i.e. to XML signatures that do not incorporate the qualifying information on 
the signature, the signer or the signed data object(s) specified in the present document. 

Throughout the rest of the document the terms "qualifying information", "properties" or "qualifying properties" will be 
used to refer to the information added to the XMLDSIG to get an XML advanced electronic signature as specified in the 
European Directive and with long term validity. 

For the present document the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the present document are to be 
interpreted as described in RFC 21 19 [10]. 
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Scope 



The present document defines XML formats for advanced electronic signatures that remain vaHd over long periods, are 
compliant the European Directive and incorporate additional useful information in common uses cases. This includes 
evidence as to its validity even if the signer or verifying party later attempts to deny (repudiates) the validity of the 
signature. 

The present document is based on the use of public key cryptography to produce digital signatures, supported by public 
key certificates. 

The present document uses a signature policy, implicitly or explicitly referenced by the signer, as one possible basis for 
establishing the validity of an electronic signature. 

The present document uses time-stamps or trusted records (e.g. time-marks) to prove the validity of a signature long 
after the normal lifetime of critical elements of an electronic signature and to support non-repudiation. It also specifies 
the optional use of additional time-stamps to provide very long-term protection against key compromise or weakened 
algorithms. 

The present document then, specifies the use of the corresponding trusted service providers (e.g. time-stamping 
authorities), and the data that needs to be archived (e.g. cross certificates and revocation lists). An advanced electronic 
signature aligned with the present document can, in consequence, be used for arbitration in case of a dispute between 
the signer and verifier, which may occur at some later time, even years later. 

The present document builds on the standards for Electronic Signatures defined in: 

• IETF W3C: "XML-Signature Syntax and Processing" [3]; 

• TS 101 733: "Electronic Signature Formats" [1]; 

• ITU-T Recommendation X.509: "Information technology - Open Systems Interconnection - The Directory: 
Authentication framework" [6]; 

• TS 101 861: "Time stamping profile" [7]. 

NOTE: See clause 2 for a full set of references. 

The present document, being built on the framework defined in [3] makes use of the terms defined there. Some of the 
definitions in [3] are repeated in the present document for the sake of completeness. 

The present document: 

• shows a taxonomy of the qualifying information (properties) that have to be present in an electronic signature to 
remain valid over long periods, to satisfy common use cases requirements, and to be compliant with the European 
Directive; 

• specifies XML schema definitions for new elements able to carry or to refer to the aforementioned properties; 

• specifies two ways for incorporating the qualifying information to XMLDSIG, namely either by direct 
incorporation of the qualifying information or using references to such information. Both ways make use of 
mechanisms defined in XMLDSIG. 

Clause 2 in the present document contains references to relevant documents and standards. 

Clause 4 gives an overview of the various types of advanced electronic signatures defined in the present document. 

Clause 5 contains the namespace specification for the XML schema definitions appearing in the present document. 

Clause 6 describes how the qualifying information is added to XMLDSIG. 

Clause 7 contains the details (including schema definitions) of the elements where the qualifying information is 
included. 

Clause 8 specifies conformance requirements for claiming endorsement to the present document. 
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Annex A contains definitions for relevant concepts used throughout the present document. 

Annex B, which is informative, defines extended formats of advanced electronic signatures that include validation data 
and time-stamps for archival. 

Annex C contains the whole set of schema definitions for the elements defined in the present document. 

Annex D contains the non normative DTD corresponding to the aforementioned schema. 

Annex E shows examples of how to incorporate qualifying information leading to the XML Advanced Electronic 
Signatures. 

Annex F contains bibliography. 
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3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ASNl Abstract Syntax Notation 1 

CA Certification Authority 

CARL Certification Authority Revocation List 



ETSI 



ETSI TS 101 903 VI .2.2 (2004-04) 



CMS Cryptographic Message Syntax 

CRL Certificate Revocation List 

DTD Document Type Definition 

HTTP Hyper Text Transfer Protocol 

OCSP Online Certificate Status Protocol 

OID Object IDentifier 

PKC Public Key Certificate 

SP Signature Policy 

TSA Time-Stamping Authorities 

TSP Trusted Service Providers 

TSU Time Stamping Unit 

URI Uniform Resource Identifier 

URN Uniform Resource Name 

XAdES XML Advanced Electronic Signature 

XAdES-A XML Advanced Electronic Signature with archiving validation data 

XAdES-BES XAdES Basic Electronic Signature 

XAdES -C XAdES with Complete validation data 

XAdES -EPES XAdES Explicit Policy based Electronic Signature 

XAdES -T XAdES with Time-Stamp 

XAdES -X XML Advanced Electronic Signature with eXtended validation data 

XML extensible Markup Language 

XML-DIGSIG Xml digital signatures 

XMLDSIG XML-Signature Syntax and Processing 

XSLT Extensible Stylesheet Language (XSL) Transformations 



Overview 



4.1 Major Parties 

The following are the major parties involved in a business transaction supported by electronic signatures as defined in 
the present document: 

• the Signer; 

• the Verifier; 

• Trusted Service Providers (TSP); 

• the Arbitrator. 



The Signer is the entity that creates the electronic signature. When the signer digitally signs over data object(s) 
(see definition) using the prescribed format, this represents a commitment on behalf of the signing entity to the data 
object(s) being signed. 

The Verifier is the entity that verifies the electronic signature. It may be a single entity or multiple entities. 

The Trusted Service Providers (TSPs) are one or more entities that help to build trust relationships between the signer 
and verifier. They support the signer and verifier by means of supporting services including user certificates, 
cross-certificates, time-stamping tokens, CRLs, ARLs, OCSP responses. The following TSPs are used to support the 
functions defined in the present document: 

Certification Authorities; 

Registration Authorities; 

Repository Authorities (e.g. a directory); 

Time-Stamping Authorities; 

Time-Marking Authorities; 
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• Signature Policy Issuers; 

• Attribute Authorities. 

Certification Authorities (CA) provide users with pubhc key certificates. 

Registration Authorities allow the identification and registration of entities before a CA generates certificates. 

Repository Authorities publish CRLs issued by CAs, signature policies issued by signature policy issuers and 
optionally public key certificates. 

Time-Stamping Authorities (TSA) attest that some data object was formed before a given trusted time. 

Time-Marking Authorities record that some data was formed before a given trusted time. 

Signature Policy Issuers define the technical and procedural requirements for electronic signature creation and 
validation, in order to meet a particular business need. 

Attributes Authorities provide users with attributes linked to public key certificates. 

An Arbitrator is an entity that arbitrates in disputes between a signer and a verifier. 



4.2 Signatures policies 



The present document includes the concept of signature policies that can be used to establish technical consistency 
when validating electronic signatures. When a comprehensive signature policy used by the verifier is either explicitly 
indicated by the signer or implied by the data being signed, then a consistent result can be obtained when validating an 
electronic signature. When the signature policy being used by the verifier is neither indicated by the signer nor can be 
derived from other data, or the signature policy is incomplete then verifiers, including arbitrators, may obtain different 
results when validating an electronic signature. Therefore, comprehensive signature policies that ensure consistency of 
signature validation are recommended from both the signers and verifiers point of view. 

Specification of the contents of signature policies is outside the scope of the current document. Further information on 
signature policies is provided in TR 102 038 [12]. 

4.3 Signature properties and signature forms 

The present document defines a set of signature properties that MAY be combined to obtain electronic signature forms 
providing satisfaction of different requirements. Below follows a short overview of the properties: 

• SignaturePolicyldentif ier. This property contains information being an unambiguous way for 
identifying the signature policy under which the electronic signature has been produced. This will ensure that 
the verifier will be able to use the same signature policy during the verification process. A signature policy is 
useful to clarify the precise role and commitments that the signer intends to assume with respect to the signed 
data object, and to avoid claims by the verifier that a different signature policy was implied by the signer. 
Details on this property can be found in clause 7.2.3. 

• Validation data properties. The present document defines a number of XML types able to contain both 
validation data (certificate chains, CRLs, OCSP responses, etc) and references to them (identifiers of 
certificates, CRLs, OCSP responses, etc). Properties of these types allow the incorporation in a signature of all 
the material that has been used in its validation. They can be jointly used with time-stamp properties to provide 
long term validity. Below follows the list of properties: 

CompleteCertif icateRef s. It contains references to the CA certificates used to validate the 
signature. Details on this property can be found in clause 7.4.1. 

CompleteRevocationRef s. It contains references to the full set of revocation information used for 
the verification of the electronic signature. Details on this property can be found in clause 7.4.2. 

AttributeCertf icateRef s. It contains references to the full set of Attribute Authorities 
certificates that have been used to validate the attribute certificate. Details on this property can be found 
in clause 7.4.3. 
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AttributeRevocationRef s. It contains references to the full set the references of Attribute 
Certificate Revocation List and/or OCSP responses that have been used in the validation of the attribute 
certificate(s) present in the signature. Details on this property can be found in clause 7.4.4. 

Certif icateValues. It contains the values of certificates used to validate the signature. Details on 
this property can be found in clause 7.6.1. 

RevocationValues. It contains the full set of revocation information used for the verification of the 
electronic signature. Details on this property can be found in clause 7.6.2. 

Time-stamp properties. The present document defines a XML type (TimeStampType) for allowing the 
inclusion of a time-stamps in a XMLDSIG signature. TimeStampType is defined in clause 7.1.4. The 
present document uses TimeStampType for defining several time-stamp properties, each one containing a 
time-stamp that covers different parts of the signature (common elements defined in XMLDSIG, validation 
data, qualifying properties, etc). Below follows the list: 

SignatureTimeStamp. Its time-stamp covers the digital signature value element. Details on this 
property can be found in clause 7.3. 

AllDataOb jectsTimeStamp. Its time-stamp covers all the signed data objects. Details on this 
property can be found in clause 7.2.9. 

IndividualDataOb jectsTimeStamp. Its time-stamp covers selected signed data objects. Details 
on this property can be found in clause 7.2.10 

SigAndRef sTimeStamp. Its time-stamp covers the signature and references to validation data. 
Details on this property can be found in clause 7.5. 1. 

Ref sOnlyTimeStamp. Its time-stamp covers only references to validation data. Details on this 
property can be found in clause 7.5.2. 

ArchiveTimeStamp. Its time-stamp covers signature and other properties required for providing 
long-term validity. Details on this property can be found in clause 7.7. 

Other properties. The present document defines a number of additional properties that can be useful in a wide 
range of environments, namely: 

SigningCertif icate. This property contains an unambiguous reference to the signer's 
certificate, formed by its identifier and the digest value of the certificate. Its usage is particularly 
important when a signer holds a number of different certificates containing the same public key, to avoid 
claims by a verifier that the signature implies another certificate with different semantics. This is also 
important when the signer holds different certificates containing different public keys in order to provide 
the verifier with the correct signature verification data. Finally, it is also important in case the issuing key 
of the CA providing the certificate would be compromised. Details on this property can be found in 
clause 7.2.2. 

SigningTime. This property contains the time at which the signer claims to have performed the 
signing process. Details on this property can be found in clause 7.2.1. 

DataObject Format. This property identifies the format of a signed data object (when electronic 
signatures are not exchanged in a restricted context) to enable the verifier to be presented or use it (text, 
sound or video) in exactly the same way as intended by the signer. Details on this property can be found 
in clause 7.2.5. 

CommitmentTypelndication. This property identifies the commitment undertaken by the signer in 
signing (a) signed data object(s) in the context of the selected signature policy (when an explicit 
commitment is being used). This will be required where a Signature Policy specifies more than a single 
commitment type, each of which might have different legal interpretations of the intent of the signature 
(e.g. proof of origin, proof of receipt, proof of creation, etc.). Details on this property can be found in 
clause 7.2.6. 

SignatureProductionPlace. This property contains the indication of the purported place where 
the signer claims to have produced the signature. Details on this property can be found in clause 7.2.7. 
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SignerRole. This property contains claimed or certified roles assumed by the signer in creating the 
signature. Details on this property can be found in clause 7.2.8. 

Countersignature. This property contains signature(s) produced on the signature. Details on this 
property can be found in clause 7.2.4. 

The aforementioned properties are defined in the normative part of the present document. They can be combined to 
generate different electronic signature forms. Some of them are defined in clause 4.3 of its normative part. Additional 
extended forms are defined in the informative annex B. Clause 8 specifies conformance requirements for claiming 
endorsement to the present technical specification. 



4.4 Electronic signature forms 



The current clause specifies three forms of XML advanced electronic signatures, namely the Basic Electronic 
Signature (XAdES-BES), the Explicit Policy based Electronic Signature (XAdES-EPES), and the Electronic 
Signature with Complete Validation Data (XAdES-C). Conformance to the present document mandates the signer to 
create one of these formats. 

The informative annex B defines extended forms of XAdES. Conformance to the present document does not mandate 
the signer to create none of the forms defined in annex B. 

4.4.1 Basic electronic signature (XAdES-BES) 

A Basic Electronic Signature (XAdES-BES) in accordance with the present document will build on a XMLDSIG by 
incorporating qualifying properties defined in the present specification. They will be added to XMLDSIG within one 
ds : Ob j e ct acting as the bag for the whole set of qualifying properties, or by using the mechanism defined in clause 
6.3.2 that allows further distribution of the properties. 

Some properties defined for building up this form will be covered by the signer's signature (signed qualifying 
information grouped within one new element, SignedProperties, see clause 6.2.1). Other ones will be not covered 
by the signer's signature. 

In a XAdES-BES the signature value SHALL be computed in the usual way of XMLDSIG over the data object(s) to be 
signed and on the whole set of signed properties when present (SignedProperties element). 

For this form it is mandatory to protect the signing certificate with the signature, in one of the two following ways: 

• Either incorporating the SigningCertif icate signed property, or 

• Not incorporating the SigningCertif icate but incorporating the signing certificate within the 
ds : Key Info element and signing it. 

A XAdES-BES signature MUST, in consequence, contain at least one of the following elements with the specified 
contents: 

• The SigningCertif icate signed property. This property MUST contain the reference and the digest 
value of the signing certificate. It MAY contain references and digests values of other certificates (that MAY 
form a chain up to the point of trust). 

• The ds : Keyinf o element. If SigningCertif icate is present in the signature, no restrictions apply to 
this element. If SigningCertif icate element is not present in the signature, then the following 
restrictions apply: 

the ds : Keyinf o element MUST include a ds : X509Data containing the signing certificate; 

the ds : Key Info element also MAY contain other certificates forming a chain that MAY reach the 
point of trust; 

the ds : Signedinf o element MUST contain a ds : Reference element referencing ds : Keyinf o, 
so that the last one is included in the signature value computation. In this way, the signing certificate is 
secured by the signature. 
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By incorporating one of these elements, XAdES-BES prevents the simple substitution of the signer's certificate 
(see clause 7.2.2). 

A XAdES-BES signature MAY also contain the following properties: 

the SigninTime signed property; 

the DataObject Format signed property; 

the CommitmentTypelndication signed; 

the SignerRole signed property; 

the SignatureProductionPlace signed property; 

one or more IndividualDataOb jectsTimeStamp or AllDataOb jectTimeStamp signed 
properties; 

one or more Countersignature unsigned properties. 

Below follows the structure of the XAdES-BES built by direct incorporation of the qualifying information in the 
corresponding new XML elements to the XMLDSIG (see clause 6.3.1 for further details). In the example "?" denotes 
zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences. 

The XML schema definition in clause 5 defines the prefix "ds" for all the XML elements already defined in 
XMLDSIG, and states that the default namespace is the one defined for the present document. In consequence, in the 
example of this clause, the elements already defined in XMLDSIG appear with the prefix "ds", whereas the new XML 
elements defined in the present document appear without prefix. 

XMLDSIG 
I 
<ds : Signature ID?>- ------- -+- - - - -+ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds :Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ?- -------- 



<ds :Object> 

<Qualif yingProperties> 
<SignedProperties> 

<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb jectsTimeStamp) 

</ SignedD at aObjectP roper ties> 

</SignedProperties> 
<UnsignedProperties> 
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<UnsignedSignatureProperties> 

(Countersignature) * 
</UnsignedSignatureProperties> 

</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 

</ds : Signature>- ----------- 



- - - + 

I 
XAdES-BES 



Other XMLDSIG ds : Ob j e ct elements with different contents MAY be added within the structure shown above to 
satisfy requkements other than the ones expressed in the present document. This also applies to the rest of the examples 
of structures of XAdES forms shown in this clause. 

The signer's conformance requirements of a XAdES-BES are defined in clause 8.1. 

NOTE: The XAdES-BES is the minimum format for an electronic signature to be generated by the signer. On its 
own, it does not provide enough information for it to be verified in the longer term. For example, 
revocation information issued by the relevant certificate status information issuer needs to be available for 
long term validation (see clause 4.3.3). 

The XAdES-BES satisfies the legal requirements for electronic signatures as defined in the European Directive on 
electronic signatures. It provides basic authentication and integrity protection. 

The semantics of the signed data of a XAdES-BES or its context may implicitly indicate a signature poUcy to the 
verifier. 

4.4.2 Explicit policy electronic signatures (XAdES-EPES) 



An Explicit Policy based Electronic Signature (XAdES-EPES) form in accordance with the present document, 
extends the definition of an electronic signature to conform to the identified signature policy. A XAdES-EPES builds up 
on a XMLDSIG or XAdES-BES forms by incorporating a signed property (SignaturePolicyldentif ier) 
indicating that a signature policy that is mandatory to use to validate the signature and specifies explicitly the signature 
policy that shall be used. This signed attribute is protected by the signer's signature. The signature may also have other 
signed properties required to conform to the mandated signature policy. 

Clause 7.2.3 provides the details on the specification of SignaturePolicyldentif ier property. Specification of 
the contents of signature policies is outside the scope of the current document. 

Further information on signature policies is provided in TR 102 038 [12]. 

The structure of the XAdES-EPES built on XAdES-BES by direct incorporation of the quaUfying information to a 
XAdES-BES form, is illustrated below: 



<ds : Signature ID?>- ------ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds:Reference URI? > 
(<ds : Transf orms>) ? 
<ds :DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ?- ------- 



<ds :Object> 



XMLDSIG 

I 
- - -+- 
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<Qualif yingProperties> 
<SignedProperties> 

<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignaturePol icy Identifier) 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb ject s Time St amp) 

</SignedDataOb jectProperties> 

</SignedProperties> 

<UnsignedProperties> 

<UnsignedSignatureProperties> 

(Countersignature) * 
</UnsignedSignatureProperties> 

</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 

</ds : Signature>- ------------- 



- - - + 

I 
XAdES-PES 



The signer's conformance requirements of XAdES-EPES are defined in clause 8.2. 

4.4.3 Electronic signature formats witin validation data 

Validation of an electronic signature in accordance with the present document requires additional data needed to 
validate the electronic signature. This additional data is called validation data; and includes: 

• PubHc Key Certificates (PKCs); 

• revocation status information for each PKC; 

• trusted time-stamps applied to the digital signature or a time-mark that shall be available in an audit log; 

• when appropriate, the details of a signature policy to be used to verify the electronic signature. 

The validation data may be collected by the signer and/or the verifier. When the signature policy identifier is present, it 
shall meet the requirements of the signature policy. Validation data includes CA certificates as well as revocation status 
information in the form of Certificate Revocation Lists (CRLs) or certificate status information (OCSP) provided by an 
on-line service. Validation data also includes evidence that the signature was created before a particular point in time 
this may be either a time-stamp token or time-mark. 

The present document defines properties able to contain validation data. Clauses below summarize some signature 
formats that incorporate them and their most relevant characteristics. 
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4.4.3.1 



Electronic signature witli time (XAdES-T) 



XML Advanced Electronic Signature with Time (XAdES-T) is a signature for which there exists a trusted time 
associated to the signature. The trusted time may be provided by two different means: 

• the SignatureTimeStamp as an unsigned property added to the electronic signature; 

• a time mark of the ES provided by a trusted service provider. 

A time-mark provided by a Trusted Service would have similar effect to the SignatureTimeStamp property but in 
this case no property is added to the electronic signature as it is the responsibility of the TSP to provide evidence of a 
time mark when required to do so. The management of time marks is outside the scope of the current document. 

Trusted time provides the initial steps towards providing long term vahdity. 

Below follows the structure of a XAdES-T form built on a XAdES-BES or a XAdES-EPES, by direct incorporation of a 
time-stamp token within the SignatureTimeStamp element. A XAdES-T form based on time-marks MAY exist 
without such an element. 



XMLDISG 

I 
- - +- - 



<ds : Signature ID?>- ------ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds :Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ? ------- 



<ds :Object> 

<Qualif yingProperties> 
<SignedProperties> 

<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignaturePolicyldentif ier ) ? 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb ject s Time St amp) * 

</SignedD at aOb ject P rope rties> 

</SignedProperties> 
<UnsignedProperties> 

<UnsignedSignatureProperties> 

(Countersignature) *-------+ 

(SignatureTimeStamp) + 

</UnsignedSignatureProperties>- - -+ 

</UnsignedProperties> 
</Qualif yingProperties> 
</ds :Object> 
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</ds : Signature>- 



I 

I 
XAdES-BES (-EPES) 



I 
+ 

I 
I 
I 
XAdES-T 



4.4.3.2 



Electronic signature witli complete validation data references (XAdES-C) 



XML Advanced Electronic Signature with Complete validation data references (XAdES-C) in accordance with the 
present document adds to the XAdES-T the CompleteCertif icateRef s and CompleteRevocationRef s 
unsigned properties as defined by the present document. If attribute certificates appear in the signature, then XAdES-C 
also incorporates the AttributeCertif icateRef s and the AttributeRevocationRef s elements. 

CompleteCertificateRefs element contains a sequence of references to the full set of CA certificates that have been used 
to validate the electronic signature up to (but not including) the signing certificate. 

CompleteRevocationRefs element contains a full set of references to the revocation data that have been used in the 
validation of the signer and CA certificates. 

AttributeCertif icateRef s and AttributeRevocationRef s elements contain references to the full set of 
Attribute Authorities certificates and references to the full set of revocation data that have been used in the validation of 
the attribute certificates present in the signature, respectively. 

Storing the references allows the values of the certification path, the CRLs or OCSPs responses. Attribute Authorities 
certificates and Attribute Certificate Revocation List and/or OCSP responses, to be stored elsewhere, reducing the size 
of a stored electronic signature format. 

Below follows the structure for XAdES-C built on a XAdES-T that incorporates the SignatureTimeStamp signed 
property. A XAdES-C form based on time-marks MAY exist without such element. 



XMLDISG 

I 
- - +- - 



<ds : Signature ID?>- ------ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds :Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ? ------- 



<ds :Object> 

<Qualif yingProperties> 

<SignedProperties> 

<SignedSignatureProperties> 
(SigningTime) ? 
(SigningCertif icate) ? 
(SignaturePolicyldentif ier ) ? 
(SignatureProductionPlace) ? 
(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb ject s Time St amp) 

</SignedDataOb ject Proper ties> 



+-+-+ 
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</ Signed? rope rties> 
<UnsignedProperties> 

<UnsignedSignatureProperties> 
(Countersignature) *----- 
(SignatureTimeStamp) H — - - - 
(CompleteCertif icateRef s) 
(CompleteRevocationRef s ) 
(AttributeCertificateRefs) ? 
(AttributeRevocationRef s ) ? 

</UnsignedSignatureProperties>- 



</UnsignedProperties> 
</Qualif yingProperties> 
</ds :Object> 
</ds : Signature>- - - - - - - 



I 
XAdES-BES (-EPES) 



XAdES- 




XAdES-C 



NOTE 1 : As a minimum, the signer will provide the XAdES-BES or when indicating that the signature conforms to 
an explicit signing policy the XAdES-EPES. 

NOTE 2: To reduce the risk of repudiating signature creation, the trusted time indication needs to be as close as 

possible to the time the signature was created. The signer or a TSP could provide the XAdES-T, if not the 
verifier should create the XAdES-T on first receipt of an electronic signature because the XAdES-T 
provides independent evidence of the existence of the signature prior to the trusted time indication. 

NOTE 3: The XAdES-T trusted time indications MUST be created before a certificate has been revoked or expired. 

NOTE 4: The signer and TSP MAY provide the XAdES-C to minimize this risk and when the signer does not 
provide the XAdES-C, the verifier should create the XAdES-C when the required component of 
revocation and validation data become available. This may require a grace period. 

NOTE 5: A grace period permits certificate revocation information to propagate through the revocation processes. 
This period could extend from the time an authorized entity requests certificate revocation, to when 
relying parties may be expected to have accessed the revocation information (for example, by contractual 
requirements placed on relying parties). In order to make sure that the certificate was not revoked at the 
time the signature was time-marked or time-stamped, verifiers should wait until the end of the grace 
period An illustration of a grace period is provided figure 1 . 
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Figure 1 : Illustration of a Grace Period 

The verifier's conformance requirements are defined in clause 8.3 for time stamped ES-C and clause 8.4 for time 
marked XAdES-C signatures. 



4.5 Validation process 



The Validation Process validates an electronic signature, the output status of the validation process can be: 

• invalid; 

• incomplete validation; 

• vahd. 

An Invalid response indicates that either the signature format is incorrect or that the digital signature value fails 
verification (e.g. the integrity check on the digital signature value fails or any of the certificates on which the digital 
signature verification depends is known to be invalid or revoked). 

An Incomplete Validation response indicates that the format and digital signature verifications have not failed but 
there is insufficient information to determine if the electronic signature is valid. For example; all the required 
certificates are not available or the grace period is not completed. In the case of Incomplete Validation, the electronic 
signature may be checked again at some later time when additional validation information becomes available. Also, in 
the case of incomplete validation, additional information may be made available to the application or user, thus 
allowing the application or user to decide what to do with partially correct electronic signatures. 

A Valid response indicates that the signature has passed verification and it complies with the signature validation 
policy. 

4.6 Arbitration 

XAdES-C form may be used for arbitration should there be a dispute between the signer and verifier, provided that: 

• the arbitrator knows where to retrieve the signer's certificate (if not already present), all the cross-certificates 
and the required CRLs, ACRLs or OCSP responses referenced in the XAdES-C; 

• when time-stamping in the XAdES-T is being used, the certificate from the TSU that has issued the 
time-stamp token in the ES-T format is still within its validity period; 

• when time-stamping in the XAdES-T is being used, the certificate from the TSU that has issued the 
time-stamp token in the XAdES-T format is not revoked at the time of arbitration; 

• when time-marking in the XAdES-T is being used, a reliable audit trail from the Time-Marking Authority is 
available for examination regarding the time; 
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none of the private keys corresponding to the certificates used to verify the signature chain have ever been 
compromised; 

the cryptography used at the time the XAdES-C was buih has not been broken at the time the arbitration is 
performed. 



If the signature poHcy can be explicit or implicitly identified then an arbitrator is able to determine the rules required to 
validate the electronic signature. 



5 XML namespace for the present document 

The XML namespace URI that MUST be used by implementations of the present document: 

http://uri.etsi.Org/01903/vl.2.2# 

The following namespace declarations apply for the XML Schema definitions throughout the present document: 

<?xml version="l . 0"?> 
<schema 

xmlns :xsd=" http: //www.w3 . orq/2001/XMLSchema " 

xmlns="http: //uri . etsi . org/01903/vl . 2 . 2#" 

tar get Name space="http ://uri.etsi.org/01903/vl.2.2#" 

xmlns :ds=" http: //www. w3. org/2000 /0 9/xmldsig #" 

elementFormDefault=" qualified" 
> 

<xsd: import namespace="http : //www . w3 . org/2000 /0 9/xmldsig#" 
schemaLocation="http : //www. w3 . org/TR/2 002/ 
REC-xmldsig-core-2 002 0212/xmldsig-core-schema . xsd" /> 



6 Syntax overview 

This clause introduces the syntax for adding qualifying information to an XML signature. 

Clause 6.1 lists a set of technical criteria that has been taken into account for this syntax proposal. 

Clause 6.2 specifies an XML element that acts as a container for the qualifying information. Additionally it describes 
the connection between the XML signature and this container element. 

Clause 6.3 shows two ways of incorporating such quaUfying information to XMLDSIG. 

6.1 Technical criteria 

The following considerations have been taken into account for the syntax specification for qualifying information on 
XML signatures: 

• The present document specifies how to add qualifying information to an XML signature such that it satisfies 
both the requirements for an Advanced Electronic Signature according to the European Directive On 
Electronic Signatures and for remaining valid over long period of time. TS 101 733 [1] identifies all the 
required information to be added in order to satisfy those requirements. Additionally it defines appropriate data 
structures for those qualifying properties using ASN.l, that fit for CMS [2] style electronic signatures. The aim 
of the present document is to specify similar XML quaUfying properties that carry such qualifying information 
and are used to amend XMLDSIG. 

• The new XML qualifying properties should not be the result of a stubborn translation process from ASN. 1 to 
XML. This would mean neglecting syntactic differences between CMS [2] and XMLDSIG such as the 
possible number of signers and multiple signed data objects covered by a single signature, as well as ignoring 
powerful features of the XML environment such as linking information by using Uniform Resource Identifiers 
(URI). 
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XML Schema [5] has been chosen as the normative language for defining the new XML structures in the 
present document rather than the DTD vocabulary defined in XML LO [8], since it is namespace aware, allows 
reuse of existing structures and allows a stricter definition of the allowed contents. 

• XML structures that have been defined in related XML standards such as XML Schema [5] and 
XML-Signature Syntax and Processing [3] have been reused where appropriate. 

6.2 The QualifyingProperties element 

The QualifyingProperties element acts as a container element for all the qualifying information that should be 
added to an XML signature. The element has the following structure: 

<xsd: element name=" QualifyingProperties " type="Qualif yingPropertiesType" /> 
<xsd: complexType name="Qualif yingPropertiesType "> 
<xsd: sequence> 

<xsd: element name="SignedP roper ties " type=" SignedP roper ties Type" 

minOccurs="0 "/> 
<xsd: element name="UnsignedP roper ties " 
type="UnsignedP roper ties Type" 
minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="Target " type="xsd: anyURI " use="required" /> 
<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

The qualifying properties are split into properties that are cryptographically bound to (i.e. signed by) the XML signature 
(SignedProperties), and properties that are not cryptographically bound to the XML signature 
(UnsignedProperties). The SignedProperties MUST be covered by a ds : Reference element of the 
XML signature. Alignment with the present document mandates that one SignedProperties element MUST exist. 

The mandatory Target attribute MUST refer to the Id attribute of the corresponding ds : Signature. 

The optional Id attribute can be used to make a reference to the QualifyingProperties container. 

6.2.1 The SignedProperties element 

The SignedProperties element contains a number of properties that are collectively signed by the XMLDSIG 
signature. 

Alignment with the present document mandates that an element SignedSignatureProperties MUST appear. 

Below follows the schema definition for SignedProperties element: 

<xsd:element name="SignedProperties" type="SignedPropertiesType" /> 

<xsd: complexType name=" S ignedP r ope r ties Type "> 
<xsd: sequence> 

<xsd: element name=" SignedSignatureProperties " 
type="SignedSignaturePropertiesType"/> 
<xsd: element name="SignedDataObject Proper ties " 

type="SignedDataObject Proper ties Type" minOccurs="0 "/> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 



The SignedProperties element MUST contain properties that qualify the XMLDSIG signature itself or the signer. 
They are included as content of the SignedSignatureProperties element. 

The SignedProperties element MAY also contain properties that qualify some of the signed data objects. These 
properties appear as content of the SignedDataOb jectProperties element. 



ETSI 



22 ETSI TS 1 01 903 V1 .2.2 (2004-04) 

The optional Id attribute can be used to make a reference to the SignedProperties element. 

6.2.2 The UnsignedProperties element 

The UnsignedProperties element contains a number of properties that are not signed by the XMLDSIG 
signature. 

<xsd: element name="UnsignedProperties" type="UnsignedPropertiesType" /> 

<xsd: complexType name= " Un s ignedP roper ties Type "> 
<xsd: sequence> 

<xsd: element name="UnsignedSignatureP roper ties " 

type="UnsignedSignatureP roper ties Type" minOccurs="0 " /> 
<xsd: element name="UnsignedDataObject Proper ties " 

type="UnsignedDataObject Proper ties Type" minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType > 

The UnsignedProperties element MAY contain properties that qualify XML signature itself or the signer. They 
are included as content of the UnsignedSignatureProperties element. 

The UnsignedProperties element MAY also contain properties that qualify some of the signed data objects. 
These properties appear as content of the UnsignedDataOb jectProperties element. 

The optional Id attribute can be used to make a reference to the UnsignedProperties element. 

6.2.3 The SignedSignatureProperties element 

This element contains properties that qualify the XML signature that has been specified with the Target attribute of 
the QualifyingProperties container element. 

<xsd: element name=" SignedSignatureProperties " 
type=" SignedSignatureProperties Type" /> 

<xsd: complexType name=" S ignedS ignat u r eP roper ties Type "> 
<xsd: sequence> 

<xsd:element name="SigningTime" type="xsd: dateTime" 

minOccurs="0 " /> 
<xsd: element name="SigningCertif icate" t ype=" Cert IDList Type" 

minOccurs="0 " /> 
<xsd: element name="SignaturePolicyIdentif er " 

type=" S ignat urePol icy Identifier Type" minOccurs=" " /> 
<xsd: element name=" S ignat ureProductionP lace" 
t ype= " S ignat ureProductionP lace Type" 
minOccurs="0 " /> 
<xsd: element name="SignerRole" type="SignerRoleType" 
minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> „ 



The optional Id attribute can be used to make a reference to the UnsignedProperties element. 

The qualifying property SigningTime is described in detail in clause 7.2.1, SigningCertif icate in 

clause 7.2.2, SignaturePolicyldentif ier in clause 7.2.3, SignatureProductionPlace in clause 7.2.7, 
and SignerRole in clause 7.2.8. 
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6.2.4 The SignedDataObjectProperties element 

This element contains properties that qualify some of the signed data objects. 

<xsd: element name=" SignedDataObjectProperties " 
type="SignedDataOb jectPropertiesType"/> 

<xsd: complexType name="SignedDataOb ject Proper ties Type" > 
<xsd: sequence> 

<xsd: element name= " D at aOb ject Format " t ype= " D at aOb ject Format Type" 

minOccurs=" " maxOccurs="unbounded" /> 
<xsd: element name=" Commitment Type Indication" 

type= "Commitment Type I ndi cat ionType" minOccurs="0 " 
maxOccur s=" unbounded" /> 
<xsd: element name="AllDataOb ject s Time St amp" type="TimeStampType" 

minOccurs=" " maxOccurs="unbounded" /> 
<xsd: element name="IndividualDataOb ject s Time St amp" 
type="TimeStampType" 

minOccurs="0 " maxOccur s=" unbounded" /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

The optional Id attribute can be used to make a reference to the UnsignedProperties element. 

The qualifying property AllDataOb jectsTimeStamp is described in detail in clause 7.2.9, 
IndividualDataOb jectsTimeStamp in clause 7.2.10, DataOb jectFormat in clause 7.2.5, and 
CommitmentTypelndication in clause 7.2.6. 

All these properties qualify the signed data object after all the required transforms have been made. 

6.2.5 The UnsignedSignatureProperties eleiTient 

This element contains properties that qualify the XML signature that has been specified with the Target attribute of 
the Qualif yingProperties container element. The content of this element is not covered by the XML signature. 

<xsd: element name=" UnsignedSignatureProperties " 
type=" UnsignedSignatureProperties Type" /> 

<xsd: complexType name= " Un s ignedS ignatureP roper ties Type "> 
<xsd: sequence> 

<xsd: element name=" Counter Signature" type=" Counter Signature Type" 

minOccurs=" " maxOccurs="unbounded" /> 
<xsd:element name="SignatureTimeStamp" type="TimeStampType" 

minOccurs="0 " maxOccur s=" unbounded" /> 
<xsd: element name="CompleteCertif icateRef s " 

type="CompleteCertificateRef slype" minOccurs="0 " /> 
<xsd: element name="CompleteRevocationRef s " 

type="CompleteRevocationRef slype" minOccurs=" " /> 
<xsd: element name= "AttributeCert if icateRef s " 

t ype="CompleteCert if icateRef s Type" minOccurs="0 " /> 
<xsd: element name="AttributeRevocationRef s " 

type="CompleteRevocationRef slype" minOccurs="0 " /> 
<xsd: choice> 

<xsd: element name=" SigAndRef sTimeStamp" type="TimeStampType" 
minOccurs=" " maxOccurs="unbounded" /> 

<xsd: element name="Ref sOnlyTimeStamp" type="TimeStampType" 
minOccurs="0 " maxOccur s=" unbounded" /> 
</xsd: choice> 
<xsd: element name="Certif icateValues " t ype= " Cert ificateValues Type" 

minOccurs = " " /> 
<xsd: element name="RevocationValues " type="RevocationVa lues Type" 

minOccurs="0 "/> 
<xsd: element name="ArchiveTimeStamp" type="TimeStampType" 
minOccurs="0 " maxOccurs="unbounded" /> 



ETSI 



24 ETSI TS 1 01 903 V1 .2.2 (2004-04) 

</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

The optional Id attribute can be used to make a reference to the UnsignedProperties element. 

The qualifying property Countersignature is described in detail in clause 7.2.4, SignatureTimeStamp in 
clause 7.3, CompleteCertif icateRef s in clause 7.4.1, CompleteRevocationRef s in clause 7.4.2, 
AttributeCertif icateRef s in clause 7.4.3, AttributeRevocationRef s in clause 7.4.4, 
SigAndRef sTimeStamp in clause 7.5.1, Ref sOnlyTimeStamp in clause 7.5.2, Certif icateValues in 
clause 7.6.1, RevocationValues in clause 7.6.2, and ArchiveTimeStamp in clause 7.7.1. 

6.2.6 The UnsignedDataOb jectProperties element 

This element contains properties that qualify some of the signed data objects. The signature generated by the signer 
does not cover the content of this element. 

<xsd: element name=" UnsignedDataOb jectProperties " 
type="UnsignedDataObject Proper tie slype" /> 

<xsd: complexType name="UnsignedDataOb ject Proper tie slype "> 
<xsd: sequence> 

<xsd: element name="UnsignedDataOb ject Property " type=" Any Type" 
minOccurs=" " maxOccurs="unbounded" /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

The optional Id attribute can be used to make a reference to the UnsignedProperties element. 

TS 101 733 [1] does not specify the usage of any unsigned property qualifying the signed data object. The present 
document, however, incorporates this element for the shake of completeness and to cope with potential future needs for 
inclusion of such kind of properties. The schema definition leaves open the definition of the contents of this type. The 
type AnyType is defined in clause 7.1.1. 

6.3 Incorporating qualifying properties into an XML signature 

The present document utilizes the ds : Ob j ect auxiliary element from XMLDSIG [3]. It MUST be used to incorporate 
the qualifying properties into the XMLDSIG signature. In principle, two different means are provided for this 
incorporation: 

• direct incorporation means that a QualifyingProperties element is put as a child of the ds : Ob ject; 

• indirect incorporation means that a QualifyingPropertiesRef erence element is put as a child of the 
ds : Object. This element contains information about a QualifyingProperties element that is stored 
in place different from the signature (see clause 6.3.2). 

However, the following restrictions apply for using ds : Object, QualifyingProperties and 
QualifyingPropertiesRef erence: 



• 



all instances of the QualifyingProperties and the QualifyingPropertiesReference element 
MUST occur within a single ds : Ob ject element; 

at most one instance of the QualifyingProperties element MAY occur within this single ds : Object 
element; 
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all signed properties MUST occur within a single QualifyingProperties element. This element can either be a 
child of the ds : Ob j ect element (direct incorporation), or it can be referenced by a 
QualifyingPropertiesRef erence element. See clause 6.3.1 for information how to sign properties; 

zero or more instances of the QualifyingPropertiesRef erence element MAY occur within the 
single ds : Ob ject element. 

No restrictions apply to the relative position of the ds : Object containing the QualifyingProperties or 
QualifyingPropertiesRef erence with respect to others ds : Object elements present within 

ds : Signature. 

It is out of the scope of the present document to specify the mechanisms required to guarantee the correct storage of the 
distributed QualifyingProperties elements (i.e. that the properties are stored by the entity that has to store them 
and that they are not undetectable modified). 



6.3.1 Signing properties 



As has already been stated, all the properties that should be protected by the signature have to be collected in a single 
instance of the QualifyingProperties element. Actually these properties are children of the 
SignedProperties child of this element. 

In order to protect the properties with the signature, a ds : Reference element MUST be added to the XMLDSIG 
signature. This ds : Reference element MUST be composed in such a way that it uses the SignedProperties 
element mentioned above as the input for computing its corresponding digest. 

Additionally, the present document MANDATES the use of the Type attribute of this particular ds : Reference 
element, with its value set to: 

http://uri.etsi. org /01903/vl. 2. 2 #SignedP roper ties 

This value indicates that the data used for hash computation is a SignedProperties element and therefore helps a 
verifying application to detect the signed properties of a signature conforming to the present document. 

If the QualifyingProperties element containing the SignedProperties element is stored in a place 
different from the signature (indirect incorporation), the result of processing the URI and transforms in this 
ds : Reference element MUST be the same as the result of processing the URI and transforms in the 
QualifyingPropertiesReference element pointing to the aforementioned QualifyingProperties 
element. 

6.3.2 Tine QualifyingPropertiesReference element 

This element contains information about a QualifyingProperties element that is stored in place different from 
the signature, for instance in another XML document. 

<xsd: element name="QualifyingPropertiesRef erence" 
type="Qualif yingPropertiesRef erenceType" /> 

<xsd: complexType name="Qualif yingPropertiesRef erenceType "> 

<xsd: sequence> 

<xsd: element ref="ds : Transforms" minOccurs="0"/> 

</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="required"/> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

The mandatory URI attribute provides an identifier for the location of the QualifyingProperties element. This 
could be for instance a URL to a web site where the information can be retrieved, or a name that the participating 
applications can use to identify a particular QualifyingProperties element. 
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The optional ds : Transforms element can be used to specify a chain of transformations that has to be applied to the 
data referenced by the URI attribute in order to get the actual representation of the QualifyingProperties 
element. The processing model for the chain of transformations is as defined in clause 4.3.3.2 of XMLDSIG [3]. 

The optional Id attribute can be used to make a reference to the QualifyingPropertiesReference element. 



Qualifying properties syntax 



This clause describes in detail all qualifying properties which have been introduced in clause 5. It provides a rationale 
for each property as well as its XML Schema definition together with explanatory textual information. 

Clause 7. 1 summarizes a set of auxiliary structures that will be needed later on, while the remaining clauses corresponds 
to a certain qualifying property. 

Clause 7.2 describes in detail the qualifying properties that can appear in XAdES-BES and XAdES-EPES electronic 
signatures forms as described in clause 4. 

Clause 7.3 describes in detail the SignatureTimeStamp. 

Clause 7.4 describes in detail properties that contain references to validation data. 

Clause 7.5 describes in detail properties that can contain time-stamps covering references to validation data. 

Clause 7.6 describes in detail properties that can contain validation data values. 

Clause 7.7 describes in detail the ArchivalTimeStamp. 

7.1 Auxiliary syntax 

The following three auxiliary XML structures are utilized in several cases in the subsequent clauses. 

7.1 .1 The AnyType data type 

The AnyType Schema data type has a content model that allows a sequence of arbitrary XML elements that (mixed 
with text) is of unrestricted length. It also allows for text content only. Additionally, an element of this data type can 
bear an unrestricted number of arbitrary attributes. It is used throughout the remaining parts of this clause wherever the 
content of an XML element has been left open. 

<xsd: complexType name= "AnyType" inixed="true"> 

<xsd: sequence ininOccurs="0 " maxOccurs="unbounded"> 
<xsd:any namespace="##any" processContents="lax"/> 

</xsd: sequence> 

<xsd: anyAt tribute nainespace="##any "/> 
</xsd: coinplexType> 



7.1 .2 The Ob jectldentif ierType data type 

The Ob jectldentif ierType data type can be used to identify a particular data object. 

It allows the specification of an unique and permanent identifier of an object. In addition, a textual description of the 
nature of the data object, and a number of references to documents where additional information about the nature of the 
data object can be found. 

<xsd: complexType name="Ob jectldentif ierType "> 
<xsd: sequence> 

<xsd:element name="Identif ier" type=" Identif ierType" /> 

<xsd:element name="Description" type="xsd: string" minOccurs="0 " /> 

<xsd: element name= "Document at ionReferences " 
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t ype= "Document at ionReferences Type" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

The Identifier element contains a permanent identifier. Once assigned the identifier can never be re-assigned 
again. It supports both the mechanism that is used to identify objects in ASN.l and the mechanism that is usually used 
to identify objects in an XML environment: 

• in an XML environment objects are typically identified by means of an Uniform Resource Identifier, URL In 
this case, the content of Identifier consists of the identifying URI, and the optional Qualifier attribute 
is not specified; 

• in ASN. 1 an Object IDentifier (OID) is used to identify an object. To support an OID, the content of Identifier 
consists of an OID, either encoded as Uniform Resource Name (URN) or as Uniform Resource 

Identifier (URI). The optional Qualifier attribute can be used to provide a hint about the applied 
encoding (values OIDAsURN or OIDAsURI). 

Should an OID and an URI exist identifying the same object, the present document encourages the use of the URI as 
explained in the first bullet above. 

<xsd: complexType name=" Identif ierType"> 
<xsd: simpleContent> 

<xsd: extension base="xsd: anyURI "> 

<xsd: attribute name="Qualif ier" type="Qualif ierlype" 
use="optional"/> 
</xsd:extension> 
</xsd: simpleContent> 
</xsd: complexType> 

<xsd: simpleType name="Qualif ierType"> 
<xsd: restriction base="xsd: string"> 
<xsd: enumeration value=" OIDAsURI "/> 
<xsd: enumeration value="OIDAsURN" /> 
</xsd:restriction> 
</xsd: simpleType> 

The optional Description element contains an informal text describing the object identifier. 

The optional DocumentationReferences element consists of an arbitrary number of references pointing to 
further explanatory documentation of the object identifier. 

<xsd: complexType name= "Document at ionReferences Type" > 

<xsd: sequence maxOccurs="unbounded"> 

<xsd: element name= "Document at ionReference" type="xsd: anyURI " /> 

</xsd: sequence> 
</xsd: complexType> 

7.1 .3 The EncapsulatedPKIDataType data type 

The EncapsulatedPKIDataType is used to incorporate a piece of PKI data into an XML structure whereas the 
PKI data is encoded using an ASN. 1 encoding mechanism. Examples of such PKI data that are widely used at the time 
being include X.509 certificates and revocation lists, OCSP responses, attribute certificates and time-stamps. 



<xsd: complexType name="EncapsulatedPKIDataType"> 
<xsd: simpleContent> 

<xsd: extension base="xsd:base64Binary"> 

<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
<xsd: attribute name="Encoding" type="xsd: anyURI " 
use="optional"/> 
</xsd:extension> 
</xsd: simpleContent> 
</xsd: complexType> 



The content of this data type is the piece of PKI data, base64 encoded as defined in [3]. 
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The Encoding attribute is an URI identifying the encoding used in the original PKI data. So far, the two following 
URIs have been identified: 

http://uri.etsi.Org/01903/vl.2.2#DER for denoting that the original PKI data were ASN.l data encoded in DER. 

http://uri.etsi.Org/01903/vl.2.2#BER for denoting that the original PKI data were ASN. 1 data encoded in BER. 

http://uri.etsi.Org/01903/vl.2.2#CER for denoting that the original PKI data were ASN. 1 data encoded in CER. 

http://uri.etsi.Org/01903/vl.2.2#PER for denoting that the original PKI data were ASN.l data encoded in PER. 

http://uri.etsi.Org/01903/vl.2.2#XER for denoting that the original PKI data were ASN.l data encoded in XER. 
If the Encoding attribute is not present, then it is assumed that the PKI data is ASN.l data encoded in DER. 
The optional ID attribute can be used to make a reference to an element of this data type. 



7.1 .4 The TimeStampType data type 



Time-Stamps shall be used with XML Advanced Electronic Signatures in a number of use cases. The present document 
proposes a number of different properties able to contain time-stamp tokens. Each time-stamp token included in these 
properties will cover a specific set of elements and properties of an electronic signature and will satisfy, in this way, 
different requirements: 

• One property that contains a time-stamp over the SignatureValue element to protect against repudiation 
in case of a key compromise. 

• Two properties contain time-stamp tokens provided for protection against fraudulence in case of a CA key 
compromise: 

a time-stamp only over all certificate and revocation information references; 

a time-stamp computed over the signature value, the signature time-stamp and the certificate and 
revocation information references. 

• To provide for long term validity of an XML signature, a time-stamp can be applied over a signature including 
validation data values. One property is defined for this purpose. More than one instance of this property can be 
added as time goes on to the archived electronic signature. 

• Additionally, properties that contain time-stamp tokens proving that some or all the data objects to be signed 
have been created before some time, can also be added as signed properties to the XAdES. 

A time-stamp is obtained by sending the digest value of the given data to the Time-Stamp Authority (TSA). The 
returned time-stamp is a signed data that contains the digest value, the identity of the TSA, and the time of stamping. 
This proves that the given data existed before the time of stamping. 

Time-Stamps specified in the present document will be generated on selected parts of the XAdES signature element. 

Below follows the schema definition for the data type used for all the time-stamps mentioned above: 

<xsd: complexType name="TimeStampType"> 
<xsd: sequence> 

<xsd: element name="Include" type="IncludeType" 

inaxOccurs = "unbounded" /> 
<xsd: element ref ="ds : Canonical iz at ionMet hod" minOccurs="0 "/> 

<xsd: choice> 

<xsd: element name="EncapsulatedTimeStamp" 

type="EncapsulatedPKIDataType"/> 
<xsd:element name="XMLTimeStamp" type="AnyType" /> 
</xsd: choice> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<xsd: complexType name=" IncludeType"> _„ 
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<xsd: attribute name="URI" type="xsd: anyURI " use="required" /> 
<xsd: attribute name="ref erencedData" type="xsd:boolean" 
use="optional"/> 
</xsd: coinplexType> 



The sequence of Include elements is used to produce the input for the computation of the digest value that is sent to 
the TSA and is present in the time-stamp token. 

The URI attribute references the elements that are time-stamped. In time-stamps that cover ds : Reference elements, 
the attribute ref erencedData MAY be present. If present with value set to "true ", the time-stamp is computed on 
the result of processing the corresponding ds : Reference element according to the XMLDSIG processing model. If 
the attribute is not present or is present with value " false ", the time-stamp is computed on the ds : Reference 
element itself. 

When present, the optional ds : CanonicalizationMethod element will indicate the canonicalization method 
used for canonicalizing XML contents resulting after dereferencing (and processing when required) the data objects. 
When not present, the standard canonicalization method as specified by XMLDSIG MUST be used. 

The actual input to the digest computation is obtained as follows. Each Include element MUTS be processed as 
detailed below: 

1) Retrieve the data referenced in the URI attribute. 

2) If the retrieved data is a ds : Reference element and the ref erencedData attribute is set to "true" 
value, take the result of processing the retrieved ds : Reference element according to the reference 
processing model of the XMLDSIG; otherwise take the ds : Reference element itself. 

3) If the resulting data is a XML nodeset, canonicalize it. If ds : Canonicalization is present, the algorithm 
indicated by this element is used. If not, the standard canonicalization method specified by XMLDSIG is used. 

4) Concatenate the resulting octets to those ones that come from processing previous Include elements present 
in the property. 

The concatenated octets are the actual input to the digest computation. The time-stamp generated by the TSA can be 
either an ASN.l data object (as defined in [11], use EncapsulatedTimeStamp), or it can be encoded as XML 
(use XMLTimeStamp). Since at the time being there is no standard for an XML time-stamp, we provide a placeholder 
for future use. 

7.2 Properties for XAdES-BES and XAdES-EPES forms 

This clause describes in detail the qualifying properties that can appear in XAdES-BES and XAdES-EPEST forms as 
described in clause 4. 

7.2.1 The signingTime element 

The signing time property specifies the time at which the signer (purportedly) performed the signing process. 

The XML Schema recommendation [5] defines an XML type xsd : date Time that allows for the inclusion of the 
required information. This is the type selected for the SigningTime element. 

This is a signed property that qualifies the whole signature. 

At most one SigningTime element MAY be present in the signature. 

Below follows the Schema definition for this element: 

<xsd:element name="SigningTime" type="xsd: dateTime" /> ^" 
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7.2.2 The SigningCertif icate element 

In many real life environments users will be able to get from different CAs or even from the same CA, different 
certificates containing the same public key for different names. The prime advantage is that a user can use the same 
private key for different purposes. Multiple use of the private key is an advantage when a smart card is used to protect 
the private key, since the storage of a smart card is always limited. When several CAs are involved, each different 
certificate may contain a different identity, e.g. as a national or as an employee from a company. Thus when a private 
key is used for various purposes, the certificate is needed to clarify the context in which the private key was used when 
generating the signature. Where there is the possibility of multiple use of private keys it is necessary for the signer to 
indicate to the verifier the precise certificate to be used. 

Many current schemes simply add the certificate after the signed data and thus are subject to various substitution 
attacks. An example of a substitution attack is a "bad" CA that would issue a certificate to someone with the public key 
of someone else. If the certificate from the signer was simply appended to the signature and thus not protected by the 
signature, any one could substitute one certificate by another and the message would appear to be signed by some one 
else. In order to counter this kind of attack, the identifier of the certificate has to be protected by the digital signature 
from the signer. 

The SigningCertif icate property is designed to prevent the simple substitution of the certificate. This property 
contains references to certificates and digest values computed on them. 

The certificate used to verify the signature SHALL be identified in the sequence; the signature policy MAY mandate 
other certificates be present, that MAY include all the certificates up to the point of trust. 

This is a signed property that qualifies the signature. 

At most SigningCertif icate element MAY be present in the signature. 

Below follows the Schema definition: 

<xsd: element name=" SigningCertif icate" type=" Cert IDList Type "/> 

<xsd: complexType name=" Cert IDList Type "> 
<xsd: sequence> 

<xsd: element name="Cert" type="Cert IDType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name=" Cert IDType "> 
<xsd: sequence> 

<xsd: element name=" Cert Digest " type="DigestAlgAndValueType" /> 
<xsd: element name=" IssuerSerial" type="ds : X5 9lssuerSerialType" /> 
</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional" /> 
</xsd: complexType> 

<xsd: complexType name="DigestAlgAndValueType"> 
<xsd: sequence> 

<xsd: element ref ="ds : DigestMethod" /> 
<xsd: element ref ="ds : DigestValue"/> 
</xsd: sequence> 
</xsd: complexType> _-„ 

The SigningCertif icate element contains the aforementioned sequence of certificate identifiers and digests 
computed on the certificates (Cert elements). 

The element IssuerSerial contains the identifier of one of the certificates referenced in the sequence. Should the 
ds : X5 9 1 s suerSer ial element appear in the signature to denote the same certificate, its value MUST be 
consistent with the corresponding IssuerSerial element. 
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The element CertDigest contains the digest of one of the certificates referenced in the sequence. It contains two 
elements: ds : DigestMethod indicates the digest algorithm and ds : DigestValue contains the value of the 
digest. 

The optional URI attribute serves to indicate where the referenced certificate can be found. 

7.2.3 The SignaturePolicyldentif ier element 

The signature policy is a set of rules for the creation and validation of an electronic signature, under which the signature 
can be determined to be valid. A given legal/contractual context MAY recognize a particular signature policy as 
meeting its requirements. 

The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of 
the legal and contractual context in which it is being applied. 

To facilitate the automatic processing of an electronic signature the parts of the signature policy which specify the 
electronic rules for the creation and validation of the electronic signature also need to be in a computer processable 
form. 

If no signature policy is identified then the signature may be assumed to have been generated/verified without any 
policy constraints, and hence may be given no specific legal or contractual significance through the context of a 
signature policy. 

The present document specifies two unambiguous ways for identifying the signature policy that a signature follows: 



• 



• 



The electronic signature can contain an explicit and unambiguous identifier of a Signature Policy together with 
a hash value of the signature policy, so it can be verified that the policy selected by the signer is the one being 
used by the verifier. An explicit signature policy has a globally unique reference, which, in this way, is bound 
to an electronic signature by the signer as part of the signature calculation. In these cases, for a given explicit 
signature policy there shall be one definitive form that has a unique binary encoded value. Finally, a signature 
policy identified in this way MAY be qualified by additional information. 

Alternatively, the electronic signature can avoid the inclusion of the aforementioned identifier and hash value. 
This will be possible when the signature policy can be unambiguously derived from the semantics of the type 
of data object(s) being signed, and some other information, e.g. national laws or private contractual 
agreements, that mention that a given signature policy MUST be used for this type of data content. In such 
cases, the signature will contain a specific empty element indicating that this implied way to identify the 
signature policy is used instead the identifier and hash value. 

The signature policy identifier is a signed property qualifying the signature. 

At most one SignaturePolicyldentif ier element MAY be present in the signature. 
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Below follows the Schema definition for this type: 



<xsd: element name="SignaturePol icy Identifier" 
type="SignaturePol icy Identifier Type" /> 

<xsd: complexType name="SignaturePolicyIdentif ierType"> 
<xsd: choice> 

<xsd: element name=" SignaturePolicyld" type="SignaturePolicyIdType" /> 
<xsd: element name="SignaturePolicyImplied"/> 
</xsd: choice> 
</xsd: complexType> 

<xsd: complexType name="SignaturePolicyIdType"> 
<xsd: sequence> 

<xsd: element name="SigPolicyId" type="Object Identifier Type" /> 
<xsd:element ref="ds : Transforms" minOccurs="0 " /> 

<xsd: element name="SigPolicyHash" type="DigestAlgAndValueType" /> 
<xsd: element name="SigPolicyQualif iers " 

type="SigPolicyQualif iersListlype" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="SigPolicyQualif iersListType"> 
<xsd: sequence> 

<xsd: element name="SigPolicyQualif ier" type="AnyType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

The SignaturePolicyld element will appear when the signature policy is identified using the first alternative. The 
SigPolicyld element contains an identifier that uniquely identifies a specific version of the signature policy. The 
SigPolicyHash element contains the identifier of the hash algorithm and the hash value of the signature policy. The 
SigPolicyQualif ier element can contain additional information qualifying the signature policy identifier. The 
optional ds : Transforms element can contain the transformations performed on the signature policy document 
before computing its hash. The processing model for these transformations is described in [3]. 

Alternatively, the SignaturePolicylmplied element will appear when the second alternative is used. This empty 
element indicates that the data object(s) being signed and other external data imply the signature policy. 

7.2.3.1 Signature Policy qualifiers 

Two qualifiers for the signature policy have been identified so far: 

• a URL where a copy of the Signature Policy (SP) MAY be obtained; 

• a user notice that should be displayed when the signature is verified. 
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Below follows the Schema definition for these two elements: 

<xsd:eleinent name="SPURI" type="xsd: anyURI "/> 

<xsd: element name="SPUserNotice" type="SPUserNoticeType"/> 

<xsd: complexType name="SPUserNoticeType"> 
<xsd: sequence> 

<xsd: element name="NoticeRef " type="NoticeReferenceType" 

minOccurs=" " /> 
<xsd:element name="ExplicitText " type="xsd: string" 
minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="NoticeRef erenceType"> 
<xsd: sequence> 

<xsd:element name="Organization" type="xsd: string"/> 
<xsd: element name="NoticeNumbers" type="IntegerListType"/> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name=" IntegerListType"> 
<xsd: sequence> 

<xsd:element name="int" type="xsd: integer " minOccurs="0 " 
maxOccur s=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

The SPUserNotice element is intended for being displayed whenever the signature is validated. The 
ExplicitText element contains the text of the notice to be displayed. Other notices could come from the 
organization issuing the signature policy. The NoticeRef element names an organization and identifies by numbers 
(NoticeNumbers element) a group of textual statements prepared by that organization, so that the application could 
get the explicit notices from a notices file. 

7.2.4 The Countersignature element 

Some electronic signatures may only be valid if they bear more than one signature. This is the case generally when a 
contract is signed between two parties. The ordering of the signatures may or may not be important, i.e. one may or may 
not need to be applied before the other. 

Several forms of multiple and counter signatures need to be supported, which fall into two basic categories: 

• independent signatures; 

• embedded signatures. 

Independent signatures are parallel signatures where the ordering of the signatures is not important. Therefore an 
independent signature will not appear as a Countersignature property of another independent one. 

Embedded signatures are applied one after the other and are used where the order the signatures are applied is 
important. Multiple embedded signatures are supported using the Countersignature unsigned property. Each 
countersignature is carried in one Countersignature element added to the Signature element to which the 
countersignature is applied. 

In a qualified Signature the contents of the Countersignature element are one or more signatures 
(i.e. ds : Signature elements) of the SignatureValue in the qualified Signature. 

A countersignature can itself be qualified by a Countersignature property. Thus it is possible to construct 
arbitrarily long series of countersignatures. 

This is a unsigned property that qualifies the signature. 
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Below follows the Schema definition for this element: 

<xsd: element name="CounterSignature" type="CounterSignatureType" /> 

<xsd: complexType name="CounterSignatureType"> 

<xsd: sequence> 

<xsd: element ref ="ds : Signature "/> 

</xsd: sequence> 
</xsd: complexType> 

Figure 2 shows a countersigned Signature: 
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Figure 2: Use of Countersignature element 

7.2.5 The DataOb jectFormat element 

When presenting signed data to a human user it may be important that there is no ambiguity as to the presentation of the 
signed data object to the relying party. In order for the appropriate representation (text, sound or video) to be selected 
by the relying party a content hint MAY be indicated by the signer. If a relying party system does not use the format 
specified to present the data object to the relying party, the electronic signature may not be valid. Such a behaviour may 
have been established by the signature policy, for instance. 

The DataOb jectFormat element provides information that describes the format of the signed data object. This 
element SHOULD be present when the signed data is to be presented to human users on verification if the presentation 
format is not implicit within the data that has been signed. This is a signed property that qualifies one specific signed 
data object. In consequence, an XML electronic signature aligned with the present document MAY contain more than 
one DataOb jectFormat elements, each one qualifying one signed data object. 
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Below follows the schema definition for this element: 

<xsd: element name= " D at aObject Format " t ype= " D at aObject Format Type" /> 

<xsd: complexType name="DataOb ject Format Type" > 
<xsd: sequence> 

<xsd:element name="Description" type="xsd: string" minOccurs="0 " /> 
<xsd: element name="Object Identifier" type="Ob ject Identifier Type" 

minOccurs="0 "/> 
<xsd:element name="MimeType" type="xsd: string" minOccurs="0 "/> 
<xsd:element name="Encoding" type="xsd: anyURI " minOccurs="0 "/> 
</xsd: sequence> 

<xsd: attribute name="Ob jectRef erence" type="xsd: anyURI" 
use="required" /> 
</xsd: complexType> 

The mandatory Ob jectRef erence attribute MUST reference the ds : Reference element of the ds : Signature 
corresponding with the data object qualified by this property. 

This element can convey: 

• textual information related to the signed data object in element Description; 

• an identifier indicating the type of the signed data object in element Ob jectldentif ier; 

• an indication of the MIME type of the signed data object in element MimeType; 

• an indication of the encoding format of the signed data object in element Encoding. 

At least one element of Description, Ob jectldentif ier and MimeType MUST be present within the 
property. 

7.2.6 The CommitmentTypelndication element 

The commitment type can be indicated in the electronic signature either: 

• explicitly using a commitment type indication in the electronic signature; 

• implicitly or explicitly from the semantics of the signed data object. 

If the indicated commitment type is explicit by means of a commitment type indication in the electronic signature, 
acceptance of a verified signature implies acceptance of the semantics of that commitment type. The semantics of 
explicit commitment types indications shall be specified either as part of the signature policy or MAY be registered for 
generic use across multiple policies. 

If a signature includes a commitment type indication other than one of those recognized under the signature policy the 
signature shall be treated as invalid. 

How commitment is indicated using the semantics of the data object being signed is outside the scope of the present 
document. 

The commitment type MAY be: 

• defined as part of the signature policy, in which case the commitment type has precise semantics that is 
defined as part of the signature policy; 



• 



a registered type, in which case the commitment type has precise semantics defined by registration, under the 
rules of the registration authority. Such a registration authority may be a trading association or a legislative 
authority. 
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The definition of a commitment type includes: 

• the object identifier for the commitment; 

• a sequence of quahfiers. 

The qualifiers can provide more information about the commitment, it could provide, for example, information about 
the context be it contractual/legal/application specific. 

If an electronic signature does not contain a recognized commitment type then the semantics of the electronic signature 
is dependent on the data object being signed and the context in which it is being used. 

This is a signed property that qualifies signed data object(s). In consequence, an XML electronic signature aligned with 
the present document MAY contain more than one CommitmentTypelndication elements. 

Below follows the schema definition for this element: 

<xsd: element name=" Commitment Type Indication" 
type= "Commitment Type I ndi cat ionType" /> 

<xsd: complexType name=" Commitment Type I ndi cat ionType"> 
<xsd: sequence> 

<xsd: element name=" Commitment Type Id" 

type="Ob jectldentif ierType"/> 
<xsd: choice> 

<xsd:element name="Ob jectReference" type="xsd: anyURI" 

minOccurs="0 " maxOccurs=" unbounded" /> 
< xsd:element name="AllSignedDataOb jects" /> 
</xsd: choice> 

<xsd: element name= " Commitment TypeQualifiers " 
t ype= " Commitment TypeQualifiersLi St Type" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name= " Commitment TypeQualifiersList Type" > 
<xsd: sequence> 

<xsd: element name= " Commitment TypeQualifier" 
type="AnyType" minOccurs="0 " maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

The CommitmentTypeld element univocally identifies the type of commitment made by the signer. A number of 
commitments have been aheady identified in TS 101 733 [1], namely: 

• Proof of origin indicates that the signer recognizes to have created, approved and sent the signed data object. 
The URI for this commitment is http://uri.etsi.Org/01903/vl.2.2#ProofOfOrigin . 

• Proof of receipt indicates that signer recognizes to have received the content of the signed data object. The 
URI for this commitment is http://uri.etsi.Org/01903/vl.2.2#ProofOfReceipt . 

• Proof of delivery indicates that the TSP providing that indication has delivered a signed data object in a local 
store accessible to the recipient of the signed data object. The URI for this commitment is 
http://uri.etsi.Org/01903/vl.2.2#ProofOfDeHverv . 

• Proof of sender indicates that the entity providing that indication has sent the signed data object (but not 
necessarily created it). The URI for this commitment is http://uri.etsi.Org/01903/vl.2.2#ProofOfSender . 

• Proof of approval indicates that the signer has approved the content of the signed data object. The URI for 
this commitment is http://uri.etsi.Org/01903/vl.2.2#ProofOfApproval . 

• Proof of creation indicates that the signer has created the signed data object (but not necessarily approved, nor 
sent it). The URI for this commitment is http://uri.etsi.Org/01903/vl.2.2#ProofOfCreation . 

One Ob jectReference element refers to one ds : Reference element of the ds : Signedinf o corresponding 
with one data object qualified by this property. If some but not all the signed data objects share the same commitment, 
one Ob jectReference element MUST appear for each one of them. However, if all the signed data objects share 
the same commitment, the AllSignedDataOb jects empty element MUST be present. 



ETSI 



37 ETSI TS 1 01 903 V1 .2.2 (2004-04) 

The CommitmentTypeQualif iers element provides means to include additional qualifying information on the 
commitment made by the signer. 

7.2.7 The SignatureProductionPlace element 

In some transactions the purported place where the signer was at the time of signature creation MAY need to be 
indicated. In order to provide this information a new property MAY be included in the signature. 

This property specifies an address associated with the signer at a particular geographical (e.g. city) location. 

This is a signed property that qualifies the signer. 

An XML electronic signature aligned with the present document MAY contain at most one 
SignatureProductionPlace element. 

Below follows the schema definition for this element: 

<xsd: element name=" SignatureProductionPlace" 
type=" SignatureProductionPlace Type" /> 

<xsd: complexType name= " S ignat ureProductionP lace Type "> 
<xsd: sequence> 

<xsd: element name="City" type="xsd: string" minOccurs="0 "/> 
<xsd:element name="StateOrProvince" type="xsd: string" 

minOccurs="0 "/> 
<xsd:element name="PostalCode" type="xsd: string" minOccurs="0 " /> 
<xsd:element name="CountryName" type="xsd: string" minOccurs="0 "/> 
</xsd: sequence> 
</xsd: complexType> 



7.2.8 The signerRoie element 



While the name of the signer is important, the position of the signer within a company or an organization can be even 
more important. Some contracts may only be valid if signed by a user in a particular role, e.g. a Sales Director. In many 
cases who the sales Director really is, is not that important but being sure that the signer is empowered by his company 
to be the Sales Director is fundamental. 

The present document defines two different ways for providing this feature: 

• using a claimed role name; 

• using an attribute certificate containing a certified role. 

The signer MAY state his own role without any certificate to corroborate this claim. In which case the claimed role can 
be added to the signature as a signed qualifying property. 

Unlike public key certificates that bind an identifier to a public key. Attribute Certificates bind the identifier of a 
certificate to some attributes of its owner, like a role. The Attribute Authority will be most of the time under the control 
of an organization or a company that is best placed to know which attributes are relevant for which individual. The 
Attribute Authority MAY use or point to public key certificates issued by any CA, provided that the appropriate trust 
may be placed in that CA. Attribute Certificates MAY have various periods of validity. That period may be quite short, 
e.g. one day. While this requires that a new Attribute Certificate is obtained every day, valid for that day, this can be 
advantageous since revocation of such certificates may not be needed. When signing, the signer will have to specify 
which Attribute Certificate it selects. 

This is a signed property that qualifies the signer. 

An XML electronic signature aligned with the present document MAY contain at most one SignerRoie element. 
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Below follows the Schema definition for this element: 

<xsd:element name="SignerRole" type="SignerRoleType"/> 

<xsd: complexType name="SignerRoleType"> 
<xsd: sequence> 

<xsd: element name="ClaimedRoles " type="ClaimedRolesListType" 

minOccurs=" " /> 
<xsd: element name="Certif iedRoles " t ype= " Cert ifiedRolesList Type" 
minOccurs=" " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="ClaimedRolesListType"> 
<xsd: sequence> 

<xsd: element name="ClaimedRole" type="AnyType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name= " Cert i f iedRolesList Type" > 
<xsd: sequence> 

<xsd: element name="Certif iedRole" type="EncapsulatedPKIDataType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

This property contains a sequence of roles that the signer can play (element SignerRole). At least one of the two 
elements ClaimedRoles or Certif iedRoles MUST be present. 

The ClaimedRoles element contains a sequence of roles claimed by the signer but not certified. Additional contents 
types MAY be defined on a domain application basis and be part of this element. The namespaces given to the 
corresponding XML schemas will allow their unambiguous identification in the case these roles use XML. 

The Certif iedRoles element contains one or more wrapped DER-encoded attribute certificates for the signer. 

7.2.9 The AllDataOb jectsTimeStamp element 

The AllDataOb jectsTimeStamp element contains the time-stamp computed before the signature production, over 
the sequence formed by ALL the ds : Reference elements within the ds : Signedinf o referencing whatever the 
signer wants to sign except the SignedProperties element. 

The application MUST compose the Include elements to refer to all the ds : Reference elements except the one 
referencing the SignedProperties element. Their corresponding referencedData attribute MUST be present 
and set to "true" . 

The AllDataOb jectsTimeStamp element is a signed property. 

Several instances of this property from different TSAs can occur within the same XAdES. 

Below follows the schema definition for this element: 

<xsd: element name=" AllDataOb jectsTimeStamp" type="TimeStampType" /> 



7.2.10 The InciiviciualDataObjectsTimeStamp element 

The IndividualDataOb jectsTimeStamp element contains the time-stamp computed before the signature 
production, over a sequence formed by SOME ds : Reference elements within the ds : Signedinf o. Note that this 
sequence cannot contain a ds : Reference computed on the SignedProperties element. 

The application MUST compose the Include elements to refer to those ds : Reference elements that are to be 
time-stamped. Their corresponding referencedData attribute MUST be present and set to "true " . 
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The IndividualDataOb jectsTimeStamp element is a signed property that quahfies the signed data object(s). 
Several instances of this property can occur within the same XAdES. 
Below follows the schema definition for this element: 

<xsd: element name=" IndividualDataOb jectsTimeStamp" type="TimeStampType" /> 

7.3 The SignatureTimeStamp element 

An important property for long standing signatures is that a signature, having been found once to be valid, shall 
continue to be so months or years later. 

A signer, verifier or both MAY be required to provide on request, proof that a digital signature was created or verified 
during the validity period of the all the certificates that make up the certificate path. In this case, the signer, verifier or 
both will also be required to provide proof that all the user and CA certificates used were not revoked when the 
signature was created or verified. 

It would be quite unacceptable, to consider a signature as invalid even if the keys or certificates were later 
compromised. Thus there is a need to be able to demonstrate that the signature key was valid around the time that the 
signature was created to provide long term evidence of the validity of a signature. 

Time-stamping by a Time-Stamping Authority (TSA) can provide such evidence. A time-stamp is obtained by sending 
the hash value of the given data to the TSA. The returned time-stamp is a signed data object that contains the hash 
value, the identity of the TSA, and the time of stamping. This proves that the given data existed before the time of 
stamping. 

Time-stamping an electronic signature before the revocation of the signer's private key and before the end of the 
validity of the certificate, provides evidence that the signature has been created while the certificate was valid and 
before it was revoked. 

If a recipient wants to hold a valid electronic signature he will have to ensure that he has obtained a valid time-stamp for 
it, before that key (and any key involved in the validation) is revoked. The sooner the time-stamp is obtained after the 
signing time, the better. 

It is important to note that signatures MAY be generated "off-line" and time-stamped at a later time by anyone, for 
example by the signer or any recipient interested in the value of the signature. The time-stamp can thus be provided by 
the signer together with the signed data object, or obtained by the recipient following receipt of the signed data object. 

The validation mandated by the signature policy can specify a maximum acceptable time difference which is allowed 
between the time indicated in the SigningTime element and the time indicated by the SignatureTimeStamp 
element. If this delay is exceeded then the electronic signature shall be considered as invalid. 

The SignatureTimeStamp encapsulates the time-stamp over the ds : SignatureValue element. 

The SignatureTimeStamp element is an unsigned property qualifying the signature. A XAdES-T form MAY 
contain several SignatureTimeSamp elements, obtained from different TSAs. 

Below follows the schema definition for this element: 

<xsd: element name=" Signature Time St amp" type="TimeStampType"/> 

The application MUST compose one Include element with an URI referencing the ds : SignatureValue 
element. The input for the time-stamp has is, in consequence, the ds : SignatureValue element. 
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7.4 Properties for references to validation data 

The following sub-clauses describe in detail qualifying properties that can contain references to certificates and 
revocation values that have been used in the validation of the electronic signature. 

When dealing with long term electronic signatures, all the data used in the verification (namely, certificate path and 
revocation information) of such signatures MUST be stored and conveniently time-stamped as has been stated in 
clause 4 for arbitration purposes. Similar considerations apply to attribute certificates if they appear within the 
signature. 

In some environments, it can be convenient to add these data to the electronic signature (as unsigned properties) for 
archival purposes (see electronic signature form for archival in clause B.3.3). 

Alternatively, other systems can consider convenient, for the purpose of arbitration, to archive them elsewhere. In such 
cases each electronic signature MUST incorporate references to all these data within the signature, reducing accordingly 
the size of the stored electronic signature. This format builds up taking XAdES-T signature by incorporating additional 
data required for validation: 

• the sequence of references to the full set of CA certificates that have been used to validate the electronic 
signature up to (but not including ) the signer's certificate; 

• a full set of references to the revocation data that have been used in the validation of the signer and C A 
certificates. 

7.4.1 The CompleteCertif icateRef s element 

This clause defines the XML element able to carry the aforementioned references to the certificates: the 

CompleteCertif icateRef s element. 

This is an unsigned property that qualifies the signature. 

An XML electronic signature aligned with the present document MAY contain at most one 

CompleteCertif icateRef s element. 

Below follows the schema definition for this element: 

<xsd: element name= "CompleteCertif icateRef s " 
type="CompleteCert if icateRef sType"/> 

<xsd: complexType name= "CompleteCertif icateRef s Type" > 

<xsd: sequence> 

<xsd:element name="CertRef s" type="CertIDListType" /> 

</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
</xsd: complexType> 

The CertRef s element contains a sequence of Cert elements already defined in clause 7.2.2, incorporating the 
digest of each certificate and the issuer and serial number identifier. 

7.4.2 The CompleteRevocationRef s element 

As it was stated in the previous clause, the addition, to an electronic signature, of the full set of references to the 
revocation data that have been used in the validation of the signer and CAs certificates, provide means to retrieve the 
actual revocation data archived elsewhere in case of dispute and, in this way, to illustrate that the verifier has taken due 
diligence of the available revocation information. 

Currently two major types of revocation data are managed in most of the systems, namely CRLs and responses of on- 
line certificate status servers, obtained through protocols designed for these purposes, like OCSP protocol. 

This clause defines the CompleteRevocationRef s element that will carry the full set of revocation information 
used for the verification of the electronic signature. 

This is an unsigned property that qualifies the signature. 
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An XML electronic signature aligned with the present document MAY contain at most one 

CompleteRevocationRef s element. 

Below follows the Schema definition for this element: 

<xsd: element name="CompleteRevocationRef s" ~ 

type="CoinpleteRevocationRef sType" /> 

<xsd: complexType name="CompleteRevocationRef sType"> 
<xsd: sequence> 

<xsd:eleinent name="CRLRef s" type="CRLRef sType" minOccurs="0 " /> 
<xsd:eleinent name="OCSPRef s" type="OCSPRef sType" minOccurs="0 " /> 
<xsd: element name="OtherRef s " type="OtherCertStatusRef sType" 
minOccurs="0 "/> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
</xsd: complexType> 

<xsd: complexType name="CRLRef sType"> 
<xsd: sequence> 

<xsd: element name="CRLRef " type="CRLRef Type" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="CRLRef Type"> 
<xsd: sequence> 

<xsd: element name="DigestAlgAndValue" 

type="DigestAlgAndValueType"/> 
<xsd: element name="CRLIdentif ier" type="CRLIdentif ierType" 
minOccurs=" " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="CRLIdentif ierType"> 
<xsd: sequence> 

<xsd:element name="Issuer" type="xsd: string"/> 
<xsd:element name="IssueTime" type="xsd: dateTime" /> 
<xsd:element name="Number" type="xsd: integer " minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional"/> 
</xsd: complexType> 

<xsd: complexType name="OCSPRef sType"> 
<xsd: sequence> 

<xsd: element name="OCSPRef " type="OCSPRef Type" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="OCSPRef Type"> 
<xsd: sequence> 

<xsd: element name="OCSP Identifier" type= "OCSPIdent if ierType" /> 
<xsd: element name=" Digest AlgAndValue" 
type="DigestAlgAndValueType" 
minOccurs="0 "/> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="OCSPIdentif ierType"> 
<xsd: sequence> 

<xsd:element name="ResponderID" type="xsd: string" /> 
<xsd:element name="ProducedAt " type="xsd: dateTime"/> 
</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional" /> 
</xsd: complexType> 

<xsd: complexType name="OtherCertStatusRef sType"> 
<xsd: sequence> 

<xsd: element name="OtherRef " type="AnyType" 
maxOccurs="unbounded" /> 
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</xsd: sequence> 
</xsd: complexType> _ 

The CompleteRevocationRef s element can contain: 

• sequences of references to CRLs (CRLRef s element); 

• sequences of references to OCSPResponse data as defined in [9] (OCSPRef s element); 

• other references to alternative forms of revocation data (OtherRef s element). 

Each element in a CRLRef s sequence (CrlRef element) identifies one CRL. This identification is made by means of: 

• the digest of the entire DER encoded CRL (DigestAlgAndValue element); 

• a set of data (CRLIdentif ier element) including the issuer (Issuer element), the time when the CRL 
was issued (IssueTime element) and optionally the number of the CRL (Number element). The 
Identifier element can be dropped if the CRL could be inferred from other information. Its URI attribute 
could serve to indicate where the identified CRL is archived. 

Each element in a OCSPRef s sequence (OcspRef element) identifies one OCSP response. This identification is made 
by means of: 

• a set of data (OCSPIdentif ier element) including the name of the server that has produced the referenced 
response (ResponderlD element) and the time indication in the "ProducedAt" field of the referenced 
response (ProducedAt element). The optional URI attribute could serve to indicate where the OCSP 
response identified is archived; 

• the digest computed on the DER encoded OCSPResponse as defined in [9] (DigestAlgAndValue 
element) response, since it MAY be needed to differentiate between two OCSP responses by the same server 
with their "ProducedAt" fields within the same second. 

Alternative forms of validation data can be included in this property making use of the OtherRef s element, a 
sequence whose items (OtherRef elements) can contain any kind of information. 

7.4.3 The AttributeCertificateRefs element 

This clause defines the AttributeCertificateRefs element that will carry the references to the full set of 
Attribute Authorities certificates that have been used to validate the attribute certificate. 

This property MAY be used only when a user attribute certificate is present in the signature within the signature. It is an 
unsigned property that qualifies the signature. 

An XML electronic signature aligned with the present document MAY contain at most one 
AttributeCertificateRefs element. 

Below follows the schema definition for this element: 

<xsd: element name=" AttributeCertificateRefs " 
type="CompleteCertificateRef slype "/> 



7.4.4 The AttributeRevocationRefs element 

This property MAY be used only when a user attribute certificate is present in the signature within the signature. 

This clause defines the AttributeRevocationRefs element able to carry the references to the full set of Attribute 
Certificate Revocation List and/or OCSP responses that have been used in the validation of the attribute certificate(s) 
present in the signature. This is an unsigned property that qualifies the signature. 

An XML electronic signature aligned with the present document MAY contain at most one 
AttributeRevocationRefs element. 
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Below follows the schema definition for this element: 

<xsd: element name="AttributeRevocationRef s " 
type="CompleteRevocationRef sType" /> 



7.5 Time-Stamps on references to validation data 

This clause discusses the suitability of time-stamping the references to validation data defined in clause 7.4. 

Electronic signatures incorporating time-stamps on validation data references are needed when there is a requirement to 
safeguard against the possibility of a CA key in the certificate chain ever being compromised. A verifier MAY be 
required to provide on request, proof that the certification path and the revocation information used a the time of the 
signature were valid, even in the case where one of the issuing keys or OCSP responder keys is later compromised. 

The current document defines two ways of using time-stamps to protect against this compromise: 

• Time-stamp the sequence formed by the digital signature (ds : Signature element), the 
SignatureTimeStamp element when present in the XAdES-T form, the certification path references, the 
Attribute Authorities certificate references and the revocation status references (for both the certificates in the 
certification path and in the list of Attribute Authorities certificate), when an OCSP response is used to get the 
status of the certificate from the signer. 

• Time-stamp only the references when CRLs are used to get the status of the certificate from the signer and the 
status of the attribute certificates present in the signature. 

The signer, verifier or both MAY obtain the time-stamp. 

7.5.1 The SigAndRef sTimeStamp element 

When an OCSP response is used, it is necessary to time-stamp in particular that response in the case the key from the 
responder would be compromised. Since the information contained in the OCSP response is user specific and time 
specific, an individual time-stamp is needed for every signature received. Instead of placing the time-stamp only over 
the certification path references and the revocation information references, which include the OCSP response, the 
time-stamp is placed on the digital signature (ds : Signature element), the signature time-stamp(s) present in the 
XAdES-T form, the certification path references and the revocation status references. For the same cryptographic price, 
this will provide an integrity mechanism over the electronic signature. Any modification can be immediately detected. It 
should be noticed that other means of protecting/detecting the integrity of the electronic signature exist and could be 
used. 

The SigAndRef sTimeStamp element is an unsigned property qualifying the signature. Clause B.3.1 proposes a 
XAdES form that can incorporate one or more SigAndRef sTimeStamp elements. 

Below follows the schema definition for this element: 

<xsd: element name="SigAndRef sTimeStamp" type="TimeStampType"/> „ 

The application MUST compose the following sequence of Include elements: 

• one Include element whose URI attribute references the ds : SignatureValue element of the qualified 
XMLDSIG signature; 

• one Include element per each present SignatureTimeStamp. The URI attribute in each Include 
element will reference one SignatureTimeStamp element; 

• one Include element whose URI attribute references the CompleteCertif icateRef s property 
element; 

• one Include element whose URI attribute references the CompleteRevocationRef s property element; 



ETSI 



44 ETSI TS 1 01 903 V1 .2.2 (2004-04) 

• one element whose URI attribute references the AttributeCertif icateRef s element if this property is 
present; 

• one element whose URI attribute references the AttributeRevocationRef s element if this property is 
present. 

That is, the input for the timestamp hash computation is a sequence of the following XML elements: 

(ds : SignatureValue, SignatureTiineStamp+, CompleteCertif icateRef s, 
CompleteRevocationRef s, AttributeCertif icateRef s?, AttributeRevocationRef s?). 

7.5.2 The Ref sOniyTimeStamp element 

Time-Stamping each ES with Complete Validation Data as defined above may not be efficient, particularly when the 
same set of CA certificates and CRL information is used to validate many signatures. 

Time-Stamping CA certificates will stop any attacker from issuing bogus CA certificates that could be claimed to exist 
before the CA key was compromised. Any bogus time-stamped CA certificates will show that the certificate was 
created after the legitimate CA key was compromised. In the same way, time-stamping CA CRLs, will stop any attacker 
from issuing bogus CA CRLs which could be claimed to exist before the CA key was compromised. 

Time-Stamping of commonly used certificates and CRLs can be done centrally, e.g. inside a company or by a service 
provider. This method reduces the amount of data the verifier has to time-stamp, for example it could reduce to just one 
time-stamp per day (i.e. in the case were all the signers use the same CA and the CRL applies for the whole day). The 
information that needs to be time-stamped is not the actual certificates and CRLs but the unambiguous references to 
those certificates and CRLs. 

The hash sent to the TSA wiU be computed then over the concatenation of CompleteCertif icateRef s and 
CompleteRevocationRef s elements. 

The Ref sOnlyTimeStamp element is an unsigned property qualifying the signature 

Clause B.3.1 proposes a XAdES form that can incorporate one or more Ref sOnlyTimeStamp elements. 

Below follows the schema definition for this element: 

<xsd: element name=" Ref sOnlyTimeStamp" type="TimeStampType"/> 

The application MUST compose the following sequence of Include elements: 

• one Include element whose URI attribute references the CompleteCertif icateRef s property 
element; 

• one Include element whose URI attribute references the CompleteRevocationRef s property element; 

• one element whose URI attribute references the AttributeCertif icateRef s element if this property is 
present; 

• one element whose URI attribute references the AttributeRevocationRef s element if this property is 
present. 

That is, the input for the timestamp hash computation is a sequence of the following XML elements: 

(CompleteCertif icateRef s, CompleteRevocationRef s, AttributeCertif icateRef s?, 
AttributeRevocationRef s?)) 

7.6 Properties for validation data values 

This clause describes in detail those properties that allow the incorporation of validation data values to the electronic 
signature. Clause B.3.2 proposes a XAdES form for adding these values to the electronic signature. 
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7.6.1 The Certif icateVaiues Property element 

A verifier will have to prove that the certification path was valid, at the time of the validation of the signature, up to a 
trust point according to the naming constraints and the certificate policy constraints from an optionally specified 
signature validation policy. It will be necessary to capture all the certificates from the certification path, starting with 
those from the signer and ending up with those of the certificate from one trusted root. 

When dealing with long term electronic signatures, all the data used in the verification (including the certificate path) 
MUST be conveniently archived. In principle, the Certif icateVaiues element contains the full set of certificates 
that have been used to validate the electronic signature, including the signer's certificate. However, it is not necessary to 
include one of those certificates into this property, if the certificate is already present in the ds : Key Info element of 
the signature. The Certif icateVaiues element MAY also include the certification information for any TSUs that 
have provided the time-stamp tokens if these certificates are not already included in the time-stamp tokens as part of the 
TSUs signatures. 

In fact, both the signer certificate and all certificates referenced in the CompieteCertif icateRef s property 
(when present) element MUST be present either in the ds : Keyinf o element of the signature or in the 
Certif icateVaiues property element. In addition, all the certificates referenced in AttributeCertificateRefs when 
present, MUST also be present in the Certif icateVaiues element. 

The Certif icateVaiues is an unsigned property and qualifies the XML signature. 

An XML electronic signature aligned with the present document MAY contain at most one Certif icateVaiues 
element. 



<xsd: eiement name="Certif icateVaiues" type="Certif icateVaiuesType"/> ^ 

<xsd: compiexType name= " Cert if icateVaiues Type" > 

<xsd: choice ininOccurs = "0 " inaxOccurs = "unbounded"> 

<xsd: eiement name="EncapsuiatedX5 9Certif icate" 

type="EncapsuiatedPKIDataType"/> 
<xsd: eiement name="OtherCertif icate" type="AnyType" /> 
</xsd: choice> 

<xsd: attribute name="Id" type="xsd: ID" use="optionai" /> 
</xsd: compiexType> 

The EncapsuiatedX509Certificate element is able to contain the base64 encoding of a DER-encoded X.509 
certificate. The OtherCertif icate element is a placeholder for potential future new formats of certificates. 

7.6.2 The RevocationVaiues property element 

One way of dealing with long term electronic signatures (for instance for arbitration purposes), is to store and 
conveniently time-stamp all the revocation data used in the verification of such signatures. 

Currently two major types of revocation data are managed in most of the systems, namely CRLs and responses of 
on-line certificate status servers, obtained through protocols designed for these purposes, like OCSP protocol. 

When using CRLs to get revocation information, a verifier will have to make sure that he or she gets at the time of the 
first verification the appropriate certificate revocation information from the signer's CA. This should be done as soon as 
possible, after the grace period (section 4.4.3.2 - Note 5), to minimize the time delay between the generation and 
verification of the signature. This involves checking that the signer certificate serial number is not included in the CRL. 
The signer, the verifier or any other third party may obtain either this CRL. If obtained by the signer, then it shall be 
conveyed to the verifier. Additional CRLs for the CA certificates in the certificate path MUST also be checked by the 
verifier. It MAY be convenient to archive these CRLs within an archived electronic signature for ease of subsequent 
verification or arbitration. 

When using OCSP to get revocation information, a verifier will have to make sure that she or he gets at the time of the 
first verification an OCSP response that contains the status "valid". This should be done as soon as possible after the 
generation of the signature, after the grace period (section 4.4.3.2 - Note 5). The signer, the verifier or any other third 
party MAY fetch this OCSP response. Since OCSP responses are transient and thus are not archived by any TSP 
including CA, it is the responsibility of every verifier to make sure that it is stored in a safe place 
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The RevocationValues property element is used to hold the values of the revocation information which are to be 
shipped with the electronic signature. This property MAY also include the revocation data for any TSUs that have 
provided the time-stamp tokens if this information are not already included in the time-stamp token as part of the TSUs 
signatures. 

This is a unsigned property that quahfies the signature. 

An XML electronic signature aligned with the present document MAY contain at most one RevocationValues 
element. 

Below follows the Schema definition for this element: 

<xsd: element name=" RevocationValues " type=" RevocationValues Type" /> 

<xsd: complexType name=" RevocationValues Type "> 
<xsd: sequence> 

<xsd:element name="CRLValues" type="CRLValuesType" 

ininOccurs = "0 " /> 
<xsd:eleinent name="OCSPValues" type="OCSPValuesType" 

ininOccurs = "0 "/> 
<xsd: element name="Ot he rvalues " type="OtherCertStatusValuesType" 
minOccurs=" " /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

Revocation information can include Certificate Revocation Lists (CRLValues) or responses from an online certificate 
status server (OCSPValues). Additionally a placeholder for other revocation information (OtherValues) is 
provided for future use. 

<xsd: complexType name=" CRLValues Type "> 
<xsd: sequence> 

<xsd: element name="EncapsulatedCRLValue" 
type="EncapsulatedPKIDataType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

Certificate Revocation Lists (CRLValues) consist of a sequence of at least one Certificate Revocation List. Each 
EncapsulatedCRLValue will contain the base64 encoding of a DER-encoded X.509 CRL. 

<xsd: complexType name=" OCSPValues Type "> 
<xsd: sequence> 

<xsd: element name="EncapsulatedOCSPValue" 

type="EncapsulatedPKIDataType" maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

OCSP Responses (OCSPValues) consist of a sequence of at least one OCSP Response. The 

EncapsulatedOCSPValue element contains the base64 encoding of a DER-encoded OCSPResponse as defined 
in [9]. 

<xsd: complexType name="OtherCertStatusValuesType"> 
<xsd: sequence> 

<xsd: element name="OtherValue" type="AnyType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 



The OtherValues element provides a placeholder for other revocation information that can be used in the future. The 
Ob jectldentif ier element is used to specify the type of revocation information that is contained by the 
subsequent Value element. 
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7.7 The ArchiveTimeStamp element 

Advances in computing increase the probability of being able to break algorithms and compromise keys. There is 
therefore a requirement to be able to protect electronic signatures against this possibility. 

Over a period of time weaknesses may occur in the cryptographic algorithms used to create an electronic signature 
(e.g. due to the time available for cryptoanalysis, or improvements in cryptoanalytical techniques). Before such 
weaknesses become likely, a verifier should take extra measures to maintain the validity of the electronic signature. 
Several techniques could be used to achieve this goal depending on the nature of the weakened cryptography. In order 
to simplify matters, a single technique, called Archive validation data, covering all the cases is being presented in the 
present document. 

Archive validation data consists of the complete validation data and the complete certificate and revocation data, 
time-stamped together with the electronic signature. The Archive validation data is necessary if the hash function and 
the crypto algorithms that were used to create the signature are no longer secure. Also, if it cannot be assumed that the 
hash function used by the Time-Stamping Authority is secure, then nested time-stamps of Archived Electronic 
Signature are required. 

The potential for Trusted Service Provider (TSP) key compromise should be significantly lower than for user keys, 
because TSP(s) are expected to use stronger cryptography and better key protection. It can be expected that new 
algorithms (or old ones with greater key lengths) will be used. In such a case, a sequence of time-stamps will protect 
against forgery. Each time-stamp needs to be affixed before either the compromise of the signing key or of the cracking 
of the algorithms used by the TSA. TSAs (Time-Stamping Authorities) should have long keys (e.g. which at the time of 
drafting the present document was 2 048 bits for the signing RSA algorithm) and/or a "good" or different algorithm. 

Nested time-stamps will also protect the verifier against key compromise or cracking the algorithm on the old electronic 
signatures. 

The process will need to be performed and iterated before the cryptographic algorithms used for generating the previous 
time-stamp are no longer secure. Archive validation data MAY thus bear multiple embedded time-stamps. 

The hash sent to the TSA (messagelmprint) will be computed the sequence formed as explained below. 

The ArchiveTimeStamp element is an unsigned property qualifying the signature. Below follows the schema 
definition for this element: 

<xsd: element name="ArchiveTimeStamp" type="TimeStampType" /> 

The application MUST compose the following sequence of Include elements: 

• one Include element per each ds : Reference present within the ds : Signedlnfo element. The URI 
attribute in each Include element will reference one of these ds : Reference elements. Their 
corresponding ref erencedData attribute MUST be present and set to "true"; 

• one Include element whose URI attribute references the ds : Signedlnfo element; 

• one Include element whose URI attribute references the ds : SignatureValue element; 

• one Include element whose URI attribute references the ds : Keyinf o element if this element is present; 

• one Include element whose URI attribute references the SignatureTimeStamp element if this element 
is present; 

• one Include element per each Countersignature property, when present. The URI attribute of each 
Include element references one Countersignature element; 

• one Include element whose URI attribute references the CompleteCertif icateRef s element if this 
element is present; 

• one Include element whose URI attribute references the CompleteRevocationRef s element if this 
element is present; 



ETSI 



48 ETSI TS 1 01 903 V1 .2.2 (2004-04) 

one Include element whose URI attribute references the AttributeCertif icateRef s element if this 
element is present; 

one Include element whose URI attribute references the AttributeRevocationRef s element if this 
element is present; 

one Include element whose URI attribute references the Certif icateValues element. This property 
MUST be added if it is not already present; 

one Include element whose URI attribute references the RevocationValues element. This property 
MUST be added if it is not already present; 

one Include element per each SigAndRef sTimeStamp element if these elements are present. The URI 
attribute in each Include element will reference one SigAndRef sTimeStamp element; 

one Include element per each Ref sOnlyTimeStamp element if these elements are present. The URI 
attribute in each Include element will reference one Ref sOnlyTimeStamp element; 

one Include element per each already present XAdESArchiveTimestamp element. The URI attribute in 
each Include element will reference one XAdESArchiveTimestamp element; 

one Include element per each present ds : Object element in the signature that is not referenced by any 
ds : Reference within ds : Signedinf o. The URI attribute in each Include element will reference one 
ds :0b ject element. 



8 Conformance requirements 



The present document defines conformance requirements for the generation of XAdES-BES and XAdES-EPES. At 
least one of these two forms must be implemented. 

The present document defines conformance requirements for the verification of XAdES-BES and XAdES-EPES. At 
least one of the two forms must be implemented. 

The present document only defines conformance requirements up to an XAdES electronic signature with complete 
validation data (XAdES-C). This means that none of the extended and archive forms of Electronic Signature, specified 
in annex B, need to be implemented to get conformance to the present document. 

On verification the inclusion of optional signed and unsigned properties must be supported only to the extended that the 
signature is verifiable. The semantics of optional properties may be unsupported, unless specified otherwise by a 
signature policy. 

8.1 Basic Electronic Signature (XAdES-BES) 

A system supporting XAdES-BES signers according to the present document shall, at a minimum, support generation of 
a XML electronic signature consisting of the following components: 



• 



• 



The ds : Signature element as specified in [3]. 

At least one of the following: 

the SigningCertif icate signed property (as defined in clause 7.2.2) incorporated to the signature 
as defined in clause 6.3; 

the ds : Keyinf o element whose contents satisfy the restrictions specified in clause 4.3.1. 
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8.2 Explicit policy based Electronic Signature (XAclES-EPES) 

A system supporting policy based signers according to the present document shall, at a minimum, support generation of 
XAdES-BES, plus: 

• The SignaturePolicyldentif ier signed property (as defined in clause 7.2.3). 

8.3 Verification using time-stamping 

A system supporting verifiers according to the present document with time-stamping facilities shall, at a minimum, 
support: 

Verification of the mandated components of a XAdES -BBS electronic signature, as defined in clause 8.1. 

SignatureTimeStamp unsigned property, as defined in clause 7.3. 

CompleteCertif icateRef erences unsigned property as defined in clause 7.4.1. 

CompleteRevocationRef erences unsigned property, as defined in clause 7.4.2. 

Public Key Certificates, as defined in ITU-T Recommendation X.509 [6] (see clause 8.1). 

Either of: 

Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [6] (see clause 8.2); or 
On-line Certificate Status Protocol, as defined in RFC 2560 [9] (see clause 8.3). 

8.4 Verification using secure records 

A system supporting verifiers according to the present document shall, at a minimum, support: 

Verification of the mandated components of a XAdES-BES, as defined in clause 8.1. 

CompleteCertif icateRef erences unsigned property as defined in clause 7.4.1. 

CompleteRevocationRef erences unsigned property, as defined in clause 7.4.2. 

A record must be maintained and cannot be undetectable modified, of the electronic signature and the time 
when the signature was first validated using the referenced certificates and revocation information. 

Public Key Certificates, as defined in ITU-T Recommendation X.509 [6] (see clause 8.1). 

Either of: 

Certificate Revocation Lists, as defined in ITU-T Recommendation X.509 [6] (see clause 8.2); or 
On-line Certificate Status Protocol, as defined in RFC 2560 [9](see clause 8.3). 
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Annex A (informative): 
Definitions 



Data Object (Content/Document) (source W3C/IETF Recommendation February 2002: "XML-Signature Syntax 
and Processing") 

The actual binary/octet data being operated on (transformed, digested or signed) by an application, frequently an HTTP 
entity. Note that the proper noun Object designates a specific XML element. Occasionally we refer to a data object as a 
document or as a resource's content. The term element content is used to describe the data between XML start and end 
tags. The term XML document is used to describe data objects which conform to the XML specification. 

Signature (source W3C/IETF Recommendation February 2002: "XML-Signature Syntax and Processing") 

Formally speaking, a value generated from the application of a private key to a message via a cryptographic algorithm 
such that it has the properties of signer authentication and message authentication (integrity). (However, we sometimes 
use the term signature generically such that it encompasses AuthenticationCode values as well, but we are careful to 
make the distinction when the property of AuthenticationSigner is relevant to the exposition.) A signature may be 
(non-exclusively) described as detached, enveloping or enveloped. 

Transform (source W3C/IETF Recommendation February 2002: "XML-Signature Syntax and Processing") 

The processing of a data from its source to its derived form. Typical transforms include XML Canonicalization, XPath 
and XSLT. 

Attribute Certificate (source ITU-T Recommendation X.509 [6]:"DATA NETWORKS AND OPEN SYSTEM 
COMMUNICATIONS.DIRECTORY") 

A set of attributes of a user together with some other information, rendered unforgeable by the digital signature created 
using the private key of the certification authority which issued it. 
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Annex B (informative): 

Extended electronic signature forms 

The XAdES forms specified in clause 4.3 can be extended by addition of certain unsigned properties that are defined in 
the present document. These properties are applicable for very long term verification, and for preventing some disaster 
situations which have been identified in the normative part of the present document. The clauses below give an 
overview of the various forms of extended signature formats in the present document. 



B.1 Extended signatures with time forms (XAdES-X) 

Extended signatures with time indication forms (XAdES-X) in accordance with the present document build on 
signatures containing CompleteCertif icateRef s and CompleteRevocationRef s properties, by adding one 
or more time-stamps unsigned properties. 

Depending of what is time-stamped, there are two different types of XAdES-X signatures, namely, XAdES-X type 1 
and XAdES-X type 2. Time-stamps in both types cover, among other elements, CompleteCertif icateRef s and 
CompleteRevocationRef s properties. Time-stamps provide an integrity and trusted time protection over 
everything that is time-stamped. They protect the referenced certificates, CRLs and OCSP responses in case of a later 
compromise of a CA key, CRL key or OCSP issuer key. 

XAdES-X type 1 is built by adding one or more SigAndRef sTimeStamp properties each containing one time-stamp 
obtained from different TSAs. These time-stamps are computed on the SignatureValue element, 
SignatureTimeStamp if present, CompleteCertif icateRef s and CompleteRevocationRef s 
properties. 

XAdES-X type 2 is built by adding one or more Refs Only Time St amp properties each containing one time-stamp 
obtained from different TSAs. These time-stamps are computed on the CompleteCertif icateRef s and 
CompleteRevocationRef s properties. 

Below follows the most complete XAdES-X structure, which builds on a XAdES-C signature: 

XMLDISG 
I 
<ds : Signature ID?>- -------+------ +_+_+_+ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds:Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ? -------- 



<ds :Object> 

<Qualif yingProperties> 
<SignedProperties> 

<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignaturePolicyldentif ier ) ? 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
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(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb jectsTimeStamp) * 
</SignedDataOb jectPropertiesSigned> 

</SignedProperties> 



<UnsignedProperties> 

<UnsignedSignatureProperties> 
(Countersignature) *----- 
(SignatureTimeStamp) *- - - - 
(CompleteCertif icateRef s) 
(CompleteRevocationRef s ) 
(AttributeCertificateRefs) ? 
(AttributeRevocationRef s ) ? - 
( (SigAndRefsTimeStamp) * | 
(RefsOnlyTimeStamp) *) 

</UnsignedSignatureProperties>- 



</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 
</ds : Signature>- ----------- 



XAdES 



XAdES-T 




XAdES -C 



XAdES -X 



B.2 Extended long electronic signatures with time 
(XAdES-X-L) 

Extended long electronic signatures with time (XAdES-X-L) forms in accordance with the present document build up 
on XAdES-X types 1 or 2 by adding the Certif icateValues and RevocationValues unsigned properties 
aforementioned. 

The structure for the most complete XAdES-X-L, built on the most complete XAdES-X signature, is shown below: 



<ds : Signature ID?>- - - - - 
<ds : Signedinf o> 

<ds : CanonicalizationMethod/> 
<ds : SignatureMethod/> 
(<ds :Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds :KeyInfo>) ? ------- 

<ds :Object> 

<Qualif yingProperties> 

<SignedProperties> 



XMLDISG 
I 



+-+-+-+-+ 
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<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignaturePolicyldentif ier ) ? 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataOb jectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb ject s Time St amp) * 

</SignedDataOb jectPropertiesSigned> 

</SignedProperties> 
<UnsignedProperties> 

<UnsignedSignatureProperties> 

(Countersignature) *-------- 

(SignatureTimeStamp) *------- 

(CompleteCertif icateRef s) 
(CompleteRevocationRef s ) 
(AttributeCertificateRefs) ? 
(AttributeRevocationRef s ) ? - - - - 

( (SigAndRef sTimeStamp) * | 
(RefsOnlyTimeStamp) *) - ------ 

( Cert i f icate sValues) 
(RevocationValues ) 

</UnsignedSignatureProperties>- - - 

</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 
</ds : Signature>- -------------- 



I I I 

I I I 

I I I 

I I I 

I I I 

I I I 

- - +-+-+-+-4 

I I I I 

XAdES I I I 

I I I 

XAdES-T I I 

I I 

XAdES -C I 

I 

XAdES -X 



XAdES-X-L 



B.3 Archival electronic signatures (XAdES-A) 

Archival signatures in accordance with the present document MUST incorporate Certif icateValues, 
RevocationValues and one or more ArchiveTimeStamp unsigned properties. They MAY contain other 
properties. Each ArchiveTimeStamp element contains a time-stamp token covering among other elements, those 
ones that contain validation data (see clause 7.7). These forms are used for archival of signatures. Successive 
time-stamps protect the whole material against vulnerable hashing algorithms or the breaking of the cryptographic 
material or algorithms. 
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Below follows the structure of a XAdES-A built on a XAdES-X-L, as an example of the most complete archival form: 



XMLDISG 

I 
- +- - - 



<ds : Signature ID?>- ------ 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds :Reference (URI=) ? > 
(<ds : Transf orins>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</ds : Ref erence>) + 
</ds : Signedinf o> 
<ds : SignatureValue> 
(<ds:KeyInfo>) ? ------- 

<ds :Object> 

<Qualif yingProperties> 

<SignedProperties> 



<SignedSignatureProperties> 

(SigningTime) ? 

(SigningCertif icate) ? 

(SignaturePolicyldentif ier ) ? 

(SignatureProductionPlace) ? 

(SignerRole) ? 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 
(DataObjectFormat) * 
(CommitmentTypelndication) * 
(AllDataOb jectsTimeStamp) * 
(IndividualDataOb ject s Time St amp) * 

</SignedD at aObjectP roper ties Signed> 

</SignedProperties> 

<UnsignedProperties> 

<UnsignedSignatureProperties> 

(Countersignature) *-------- 

(SignatureTimeStamp) *------- 

(CompleteCertif icateRef s) ? 
(CompleteRevocationRef s ) ? 
(AttributeCertificateRefs) ? 
(AttributeRevocationRef s ) ? - - - - 



+-+-+-+-+-+ 
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( (SigAndRefsTimeStamp) * | 

(RefsOnlyTimeStamp) *) ? - - - 
(Certif icatesValues) 
(RevocationValues) - - - - - - 

(ArchiveTimeStamp) + 
</UnsignedSignatureProperties>- 

</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 

</ds : Signature>- ----------- 




I I I I I 



XAdES I 



XAdES-T I 



XAdES -C I 

I I 
XAdES -X I 

I 
XAdES-X-L 



XAdES -A 
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Annex C (normative): 
Schema definitions 



<?xml version="l . 0" encoding="UTF-8 " ?> 

<xsd: schema tar get Name space="http ://uri.etsi.org/01903/vl.2.2#" 

xmlns:xsd="http: //www.w3 . org/200 1/XMLSchema" 

xmlns="http: //uri . etsi . org/01903/vl . 2 . 2#" 

xmlns : ds="http : //www . w3 . org/2000 /0 9/xmldsig#" elementFormDef ault=" qualified" > 

<xsd: import namespace="http : //www . w3 . org/2000 /0 9/xmldsig#" 
schemaLocation="http : //www . w3 . org/TR/2 002/ 
REC-xmldsig-core-2 002 0212/xmldsig-core-schema . xsd" /> 

<! — Start auxiliary types definitions: AnyType, Ob ject Identif ierType, 
EncapsulatedPKIDataType and TimestampType — > 

<! — Start AnyType — > 

<xsd: element name="Any" type="AnyType" /> 
<xsd: complexType name="AnyType" mixed="true"> 

<xsd: sequence minOccurs=" " maxOccurs="unbounded"> 
<xsd:any namespace="##any " processContents="lax"/> 

</xsd: sequence> 

<xsd: anyAt tribute namespace="##any " /> 
</xsd: complexType> 

<! — End AnyType — > 

<! — Start Ob jectldentif ierType — > 

<xsd: element name= "Ob jectldentif ier" type="Ob jectldentif ierType" /> 
<xsd: complexType name="Ob jectldentif ier Type" > 
<xsd: sequence> 

<xsd:element name="Identif ier" type="Identif ierType"/> 
<xsd:element name="Description" type="xsd: string" minOccurs="0 " /> 
<xsd: element name= "Document at ionReferences " 
t ype=" Document at ionReferences Type" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="Identif ierType"> 
<xsd: simpleContent> 

<xsd: extension base="xsd: anyURI "> 

<xsd: attribute name="Qualif ier " type="Qualif ierType" 
use="optional"/> 

</xsd:extension> 
</xsd: simpleContent> 
</xsd: complexType > 

<xsd: simpleType name="Qualif ierType"> 
<xsd: restriction base="xsd: string"> 
<xsd: enumeration value="OIDAsURI "/> 
<xsd: enumeration value="OIDAsURN" /> 
</xsd:restriction> 
</xsd: simpleType> 

<xsd: complexType name="DocumentationRef erencesType"> 
<xsd: sequence maxOccurs="unbounded"> 

<xsd: element name= "Document at ionReference" type="xsd: any URI " /> 
</xsd: sequence> 
</xsd: complexType > 

<! — End Ob jectldentif ierType — > 

<! — Start EncapsulatedPKIDataType — > 

<xsd: element name="EncapsulatedPKIData" type=" EncapsulatedPKIDataType" /> 
<xsd: complexType name="EncapsulatedPKIDataType"> 
<xsd: simpleContent> 
I <xsd: extension base="xsd: base64Binary "> , 
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<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
</xsd:extension> 
</xsd: siinpleContent> 
</xsd: complexType> 

<! — End EncapsulatedPKIDataType — > 

<! — Start TimeStampType — > 

<xsd:element naine="TiineStamp" type="TimeStampType" /> 
<xsd: complexType naine="TiineStampType"> 
<xsd: sequence> 

<xsd: element name="Include" type=" IncludeType" maxOccurs="unbounded" /> 
<xsd: element ref ="ds : Canonical iz at ionMet hod" minOccurs=" " /> 
<xsd: choice> 

<xsd: element name="EncapsulatedTimeStamp" 
type="EncapsulatedPKIDataType"/> 

<xsd: element name="XMLTimeStamp" type="AnyType"/> 
</xsd: choice> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
</xsd: complexType> 

<xsd: complexType name=" IncludeType "> 

<xsd: attribute name="URI" type="xsd: anyURI " use="required" /> 

<xsd: attribute name="ref erencedData" type="xsd:boolean" use="optional"/> 

</xsd: complexType> 

<! — End TimeStampType — > 

<! — End auxiliary types definitions — > 

<! — Start container types — > 

<! — Start Qualif yingProperties — > 

<xsd: element name="Qualif yingProperties " type="Qualif yingPropertiesType" /> 

<xsd: complexType name="Qualif yingPropertiesType"> 
<xsd: sequence> 

<xsd: element name="SignedP roper ties " type=" SignedP roper tie slype" 
minOccurs="0 " /> 

<xsd: element name="UnsignedP roper ties " type="UnsignedP roper tie slype" 
minOccurs="0 "/> 

</xsd: sequence> 

<xsd: attribute name="Target " type="xsd: anyURI " use="required" /> 
<xsd: attribute name="Id" type="xsd: ID" use="optional"/> 
</xsd: complexType> 

<! — End Qualif yingProperties — > 

<!-- Start SignedProperties — > 

<xsd: element name=" SignedProperties " type=" SignedP rope rtiesType"/> 

<xsd: complexType name= " S ignedP roper ties Type "> 
<xsd: sequence> 

<xsd: element name="SignedSignatureP roper ties " 
type="SignedSignaturePropertiesType"/> 

<xsd: element name="SignedDataObject Proper ties " 
type="SignedDataObject Proper ties Type" minOccurs=" " /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<!-- End SignedProperties — > 

<! — Start UnsignedProperties — > 

<xsd:element name="UnsignedProperties" type="UnsignedPropertiesType" /> 
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<xsd: complexType name= " Un signedPr ope rties Type "> 
<xsd: sequence> 

<xsd: element name="UnsignedSignatureP rope rties " 

type="UnsignedSignatureP rope rties Type" minOccurs="0 " /> 
<xsd: element name="UnsignedDataObject Proper ties " 

type="UnsignedDataObject Proper ties Type" minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<! — End UnsignedProperties — > 

<! — Start SignedSignatureProperties — > 

<xsd: element name="SignedSignatureP rope rties " 
type=" SignedSignatureProperties Type" /> 

<xsd: complexType name="SignedSignaturePropertiesType"> 
<xsd: sequence> 

<xsd:element name="SigningTime" type="xsd: dateTime" minOccurs=" " /> 
<xsd: element name=" SigningCertif icate" t ype= " Cert IDList Type" 
minOccurs="0 " /> 

<xsd: element name="SignaturePol icy Identifier" 
type=" SignaturePol icy Identifier Type" minOccurs="0 " /> 

<xsd: element name="SignatureProductionPlace" 
type="SignatureProductionP lace Type" 
minOccurs="0 "/> 
<xsd:element name="SignerRole" type="SignerRoleType" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End SignedSignatureProperties — > 

<! — Start SignedDataOb jectProperties — > 

<xsd: element name=" SignedDataOb jectProperties " 
type="SignedDataObject Proper ties Type" /> 

<xsd: complexType name="SignedDataOb ject Proper tie slype "> 
<xsd: sequence> 

<xsd: element name= " D at aOb ject Format " t ype= " D at aOb ject Format Type" 

minOccurs=" " maxOccurs="unbounded" /> 
<xsd: element name=" Commitment Type Indication" 

type= "Commitment Type I ndi cat ionType" minOccurs=" " 
maxOccurs="unbounded" /> 
<xsd: element name="AllDataOb ject s Time St amp" type="TimeStampType" 

minOccurs="0 " maxOccurs=" unbounded" /> 
<xsd: element name="IndividualDataOb ject s Time St amp" type="TimeStampType" 
minOccurs=" " maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End SignedDataOb jectProperties — > 

<! — Start UnsignedSignatureProperties — > 

<xsd: element name="UnsignedSignatureP rope rties " 
type="UnsignedSignatureP rope rties Type" /> 

<xsd: complexType name="UnsignedSignaturePropertiesType"> 
<xsd: sequence> 

<xsd: element name=" Counter Signature" type=" Count erSignatureType" 

minOccurs="0 " maxOccur s=" unbounded" /> 
<xsd: element name="SignatureTimeStamp" type="TimeStampType" 

minOccurs="0 " maxOccur s= "unbounded" /> 
<xsd: element name="CompleteCertif icateRef s " 

type="CompleteCertificateRef slype" minOccurs="0 " /> 
<xsd: element name="CompleteRevocationRef s " 

type="CompleteRevocationRef slype" minOccurs="0 " /> 
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<xsd: element name="AttributeCertif icateRef s " 

type="CompleteCertif icateRef sType" minOccurs="0 " /> 
<xsd: element name="AttributeRevocationRef s " 

type="CompleteRevocationRef sType" minOccurs="0 " /> 
<xsd: choice> 

<xsd: element name="SigAndRef sTimeStamp" type="TimeStampType" 

minOccurs=" " maxOccurs="unbounded" /> 
<xsd: element name="Ref sOnlyTimeStamp" type="TimeStampType" 
minOccurs=" " maxOccurs="unbounded" /> 
</xsd: choice> 
<xsd: element name="Certif icateValues " 

t ype= " Cert ificateValues Type" minOccurs="0 "/> 
<xsd: element name="RevocationValues " type="RevocationVa lues Type" 

minOccurs=" " /> 
<xsd: element name="ArchiveTimeStamp" type="TimeStampType" 
minOccurs="0 " maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End UnsignedSignatureProperties — > 

<! — Start UnsignedDataOb jectProperties — > 

<xsd: element name=" UnsignedDataOb jectProperties " 
type="UnsignedDataObject Proper ties Type" /> 

<xsd: complexType name="UnsignedDataOb ject Proper ties Type" > 
<xsd: sequence> 

<xsd: element name="UnsignedDataOb ject Property " type=" Any Type" 
minOccurs=" " maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End UnsignedDataOb jectProperties — > 

<! — Start Qualif yingPropertiesRef erence — > 

<xsd: element name="Qualif yingPropertiesRef erence" 
type="Qualif yingPropertiesRef erenceType" /> 

<xsd: complexType name="Qualif yingPropertiesRef erenceType "> 

<xsd: sequence> 

<xsd:element ref="ds : Transforms" minOccurs="0 " /> 

</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="required"/> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<! — End Qualif yingPropertiesRef erence — > 

<!-- End container types — > 

<! — Start SigningTime element — > 

<xsd:element name="SigningTime" type="xsd: dateTime" /> 

<! — End SigningTime element — > 

<! — Start SigningCertif icate — > 

<xsd: element name=" SigningCertif icate" t ype=" Cert IDList Type" /> 
<xsd: complexType name=" Cert IDList Type "> 
<xsd: sequence> 

<xsd:element name="Cert" type="CertIDType" maxOccurs="unbounded"/> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name="CertIDType"> 
<xsd: sequence> 

<xsd: element name=" Cert Digest " type="DigestAlgAndValueType" /> 
<xsd: element name="IssuerSerial" type="ds : X50 9lssuerSerialType" /> 
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</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional"/> 
</xsd: complexType> 

<xsd: complexType naine="DigestAlgAndValueType"> 
<xsd: sequence> 

<xsd: element ref ="ds : DigestMethod" /> 
<xsd: element ref ="ds : Digest Value" /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End SigningCertif icate — > 

<! — Start SignaturePolicyldentif ier — > 

<xsd: element name="SignaturePol icy Identifier" 
type=" SignaturePolicyldentif ier Type" /> 

<xsd: complexType name="SignaturePolicyIdentif ierType"> 
<xsd: choice> 

<xsd: element name="SignaturePolicyId" type=" SignaturePolicyldType" /> 
<xsd: element name="SignaturePol icy Imp lied" /> 
</xsd: choice> 
</xsd: complexType > 

<xsd: complexType name="SignaturePolicyIdType"> 
<xsd: sequence> 

<xsd: element name="SigPolicyId" type="Ob ject Identif ierlype" /> 
<xsd:element ref="ds : Transforms" minOccurs=" " /> 

<xsd: element name="SigPolicyHash" type="DigestAlgAndValueType" /> 
<xsd: element name="SigPolicyQualif iers " 
type="SigPolicyQualif iersListType" minOccurs="0 "/> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name="SigPolicyQualif ier sList Type" > 
<xsd: sequence> 

<xsd: element name="SigPolicyQualif ier" type="AnyType" 
maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd:element name="SPURI" type="xsd: anyURI " /> 
<xsd:element name="SPUserNotice" type="SPUserNoticeType"/> 
<xsd: complexType name= "SPUserNot ice Type "> 
<xsd: sequence> 

<xsd: element name="NoticeRef " type="NoticeReferenceType" 
minOccurs=" " /> 

<xsd:element name="ExplicitText " type="xsd: string" minOccurs = " " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="NoticeRef erenceType"> 
<xsd: sequence> 

<xsd:element name="Organization" type="xsd: string" /> 
<xsd:element name="NoticeNumbers" type=" IntegerListType" /> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name="IntegerListType"> 
<xsd: sequence> 

<xsd:element name="int" type="xsd: integer " minOccurs="0 " 
maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End SignaturePolicyldentif ier — > 

<! — Start Countersignature — > 

<xsd: element name=" Counter Signature" t ype=" Count erSignatureType" /> 
<xsd: complexType name="CounterSignatureType"> 
<xsd: sequence> 

<xsd: element ref ="ds : Signature" /> 
</xsd: sequence> 
</xsd: complexType > 

<! — End Countersignature — > 
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<! — Start DataObjectFormat — > 

<xsd: element naine=" DataObjectFormat " type="DataOb jectFormatType"/> 
<xsd: complexType name="DataOb ject Format Type" > 
<xsd: sequence> 

<xsd:element name="Description" type="xsd: string" minOccurs="0 " /> 
<xsd: element name="Object Identifier" type="Ob ject Identifier Type" 
minOccurs="0 "/> 

<xsd:element name="MimeType" type="xsd: string" minOccurs="0 " /> 
<xsd:element name="Encoding" type="xsd: anyURI " minOccurs="0 " /> 
</xsd: sequence> 

<xsd: attribute name="Ob jectReference" type="xsd: anyURI" use="required" /> 
</xsd: complexType > 

<! — End DataObjectFormat — > 

<! — Start CommitmentTypelndication — > 

<xsd: element name=" Commitment Type Indication" 
tYpe= "Commitment Type I ndi cat ionType" /> 

<xsd: complexType name=" Commitment Type I ndi cat ionType"> 
<xsd: sequence> 

<xsd: element name=" Commitment Type Id" type="Ob ject Identifier Type" /> 
<xsd: choice> 

<xsd:element name="Ob jectReference" type="xsd: anyURI" minOccurs=" " 
maxOccurs="unbounded" /> 

<xsd: element name="AllSignedDataOb jects " /> 
</xsd: choice> 

<xsd: element name= " Commitment TypeQualifiers " 
t ype= " Commitment TypeQualifiersLi St Type" minOccurs=" " /> 
</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name= " Commitment TypeQualifiersList Type" > 
<xsd: sequence> 

<xsd: element name="CommitmentTypeQualif ier" type="AnyType" 
minOccurs="0 " maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType > 

<! — End CommitmentTypelndication — > 

<! — Start SignatureProductionPlace — > 

<xsd: element name=" SignatureProductionPlace" 
type="SignatureProductionPl ace Type "/> 

<xsd: complexType name="SignatureProductionPlaceType"> 
<xsd: sequence> 

<xsd:element name="City" type="xsd: string" minOccurs=" " /> 
<xsd:element name="StateOrProvince" type="xsd: string" minOccurs="0 " /> 
<xsd:element name="PostalCode" type="xsd: string" minOccurs=" " /> 
<xsd:element name="CountryName" type="xsd: string" minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<! — End SignatureProductionPlace — > 

<! — Start SignerRole — > 

<xsd:element name="SignerRole" type="SignerRoleType"/> 
<xsd: complexType name=" SignerRole Type "> 
<xsd: sequence> 

<xsd: element name="ClaimedRoles " type="ClaimedRolesListType" 

minOccurs="0 " /> 
<xsd: element name="Certif iedRoles " t ype= " Cert ifiedRolesList Type" 
minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="ClaimedRolesListType"> 
<xsd: sequence> 
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<xsd: element name="ClaimedRole" type="AnyType" maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name= " Cert i f iedRolesList Type" > 
<xsd: sequence> 

<xsd: element name="Certif iedRole" type="EncapsulatedPKIDataType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 

<!-- End SignerRole — > 

<xsd: element name="AllDataOb jectsTimeStamp" type="TimeStampType" /> 

<xsd: element name= " I ndi vidua ID at aOb jectsTimeStamp" type="TimeStampType" /> 

<xsd: element name=" Signature Time St amp" type="TimeStampType" /> 

<! — Start CompleteCertif icateRef s — > 

<xsd: element name= "CompleteCertif icateRef s " 
type="CompleteCert if icateRef sType"/> 

<xsd: complexType name= "CompleteCertif icateRef s Type" > 

<xsd: sequence> 

<xsd:element name="CertRef s" type="Cert IDListType" /> 

</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<! — End CompleteCertif icateRef s — > 

<! — Start CompleteRevocationRef s — > 

<xsd: element name="CompleteRevocationRef s " 
type="CompleteRevocationRef sType" /> 

<xsd: complexType name="CompleteRevocationRef sType"> 
<xsd: sequence> 

<xsd:element name="CRLRef s" type="CRLRef sType" minOccurs="0 " /> 
<xsd:element name="OCSPRef s" type="OCSPRef sType" minOccurs="0 " /> 
<xsd: element name="OtherRef s " type="OtherCertStatusRef sType" 
minOccurs="0 "/> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<xsd: complexType name="CRLRef slype "> 

<xsd: sequence> 

<xsd:element name="CRLRef " type="CRLRef Type" maxOccurs="unbounded" /> 

</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="CRLRef Type"> 
<xsd: sequence> 

<xsd: element name=" Digest AlgAndValue" type="DigestAlgAndValueType" /> 
<xsd: element name="CRLIdentif ier" type="CRLIdentif ierType" 
minOccurs=" " /> 

</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name="CRLIdentif ierType"> 

<xsd: sequence> 

<xsd:element name="Issuer" type="xsd: string"/> 
<xsd: element name="IssueTime" type="xsd: datelime" /> 
<xsd:element name="Number" type="xsd: integer " minOccurs="0 " /> 

</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional" /> 



ETSI 



63 ETSI TS 1 01 903 V1 .2.2 (2004-04) 



</xsd: complexType> 

<xsd: complexType name="OCSPRef sType"> 

<xsd: sequence> 

<xsd:element name="OCSPRef " type="OCSPRef Type" maxOccurs="unbounded" /> 

</xsd: sequence> 
</xsd: complexType > 

<xsd: complexType name="OCSPRef Type"> 
<xsd: sequence> 

<xsd: element name="OCSP Identifier" type="OCSPIdentif ierType" /> 
<xsd: element name=" Digest AlgAndValue" type="DigestAlgAndValueType" 
minOccurs="0 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: complexType name= " OCSP I dent if ierType "> 
<xsd: sequence> 

<xsd:element name="ResponderID" type="xsd: string" /> 
<xsd:element name="ProducedAt " type="xsd: dateTime"/> 
</xsd: sequence> 

<xsd: attribute name="URI" type="xsd: anyURI " use="optional"/> 
</xsd: complexType> 

<xsd: complexType name="OtherCertStatusRef sType"> 

<xsd: sequence> 

<xsd:element name="OtherRef " type="AnyType" maxOccurs="unbounded" /> 

</xsd: sequence> 
</xsd: complexType> 

<! — End CompleteRevocationRef s — > 

<xsd: element name="SigAndRef sTimeStamp" type="TimeStampType" /> 

<xsd: element name="Refs Only Time St amp" type="TimeStampType"/> 

<! — Start Certif icateValues — > 

<xsd: element name=" Cert if icateValues " type="Certif icateValuesType"/> 

<xsd: complexType name= " Cert if icateValues Type" > 

<xsd: choice minOccurs="0 " maxOccurs="unbounded"> 
<xsd: element name="EncapsulatedX50 9Certif icate" 
type="EncapsulatedPKIDataType"/> 

<xsd:element name="OtherCertif icate" type="AnyType" /> 
</xsd: choice> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<! — End Certif icateValues — > 

<! — Start RevocationValues — > 

<xsd: element name=" RevocationValues " type=" RevocationValues Type" /> 

<xsd: complexType name=" RevocationValues Type "> 
<xsd: sequence> 

<xsd:element name="CRLValues" type="CRLValuesType" minOccurs="0"/> 
<xsd:element name="OCSPValues" type="OCSPValuesType" minOccurs="0"/> 
<xsd: element name="Ot he rvalues " type="OtherCertStatusValuesType" 
minOccurs="0 "/> 
</xsd: sequence> 

<xsd: attribute name="Id" type="xsd: ID" use="optional" /> 
</xsd: complexType> 

<xsd: complexType name="CRLVa lues Type "> 
<xsd: sequence> 

<xsd: element name="EncapsulatedCRLValue" type="EncapsulatedPKIDataType" 
maxOccurs="unbounded" /> 
</xsd: sequence> 
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</xsd: complexType> 



<xsd: complexType name= "OCSPVa lues Type "> 
<xsd: sequence> 

<xsd: element name="EncapsulatedOCSPValue" 

type="EncapsulatedPKIDataType" maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: coinplexType> 

<xsd: complexType name="OtherCertStatusValuesType"> 
<xsd: sequence> 

<xsd: element name="OtherValue" type="AnyType" maxOccurs="unbounded"/> 
</xsd: sequence> 
</xsd: complexType> 

<! — End RevocationValues — > 

<xsd:element name="ArchiveTimeStamp" type="TimeStampType" /> 

</xsd: schema> 
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Annex D (informative): 
DTD 



<?xml version="l . 0" encoding="UTF-8 " ?> 

<! ENTITY % Any. ANY ' '> 

<! ENTITY % XML Time St amp. ANY ' '> 

<! — Start Any — > 

<! ELEMENT Any (#PCDATA %Any.ANY;)*> 

< ! — End Any — > 

<! — Start Ob jectldentif ier — > 

<!ELEMENT Ob jectldentif ier (Identifier, Description?, 

DocumentationRef erences? ) > 

<! ELEMENT Identifier (#PCDATA)> 

<!ATTLIST Identifier 

Qualifier (OIDAsURI | OIDAsURN) #IMPLIED 
> 

<! ELEMENT Description (#PCDATA)> 

<! ELEMENT DocumentationRef erences (DocumentationReference) +> 
<! ELEMENT DocumentationReference (#PCDATA)> 

<! — End Ob jectldentif ier — > 

<! — Start EncapsulatedPKIData — > 

<! ELEMENT EncapsulatedPKIData (#PCDATA)> 
<!ATTLIST EncapsulatedPKIData 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 

<! — End EncapsulatedPKIData — > 

<! — Start TimeStamp — > 

<! ELEMENT TimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
<!ATTLIST TimeStamp 

Id ID #IMPLIED 
> 

<! ELEMENT EncapsulatedTimeStamp (#PCDATA)> 
<!ATTLIST EncapsulatedTimeStamp 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 

<! ELEMENT Include EMPTY> 
<!ATTLIST Include 

URI CDATA #REQUIRED 

referencedData CDATA #IMPLIED 
> 

<!ELEMENT XMLTimeStamp (#PCDATA %XMLTimeStamp . ANY; ) *> 

<! — End TimeStamp — > 

<! — Start container types — > 

<! — Start Qualif yingProperties — > 

<!ELEMENT Qualif yingProperties (SignedProperties?, UnsignedProperties? ) > 



ETSI 



66 ETSI TS 1 01 903 V1 .2.2 (2004-04) 



<!ATTLIST QualifyingProperties 

Target CDATA #REQUIRED 

Id ID #IMPLIED 
> 

<!ELEMENT SignedPropert ies (SignedSignatureProperties, 
SignedDataOb jectProperties?) > 
<!ATTLIST SignedProperties 

Id ID #IMPLIED 
> 

<!ELEMENT UnsignedProperties (UnsignedSignatureProperties?, 
UnsignedDataOb jectProperties?) > 
<!ATTLIST UnsignedProperties 

Id ID #IMPLIED 
> 

<! — End QualifyingProperties — > 

<! — Start SignedSignatureProperties, SignedDataOb jectProperties, 
UnsignedSignatureProperties, UnsignedDataOb jectProperties — > 

<!ELEMENT SignedSignatureProperties (SigningTime?, SigningCertif icate?, 
SignaturePolicyldentif ier?, SignatureProductionPlace?, SignerRole?) > 
< ! ATTLIST SignedSignatureProperties 

Id ID #IMPLIED 
> 

<!ELEMENT SignedDataOb jectProperties (DataOb jectFormat*, 
Commitment Type Indication*, AllDataOb jectsTimeStamp*, 
IndividualDataOb jectsTimeStamp* ) > 
< lATTLIST SignedDataOb jectProperties 

Id ID #IMPLIED 
> 

<! ELEMENT UnsignedSignatureProperties (Countersignature*, 

Signature Time St amp*, CompleteCertif icateRef s?, CompleteRevocationRef s?, 

AttributeCertif icateRef s?, AttributeRevocationRef s?, (SigAndRef sTimeStamp* | 

Ref sOnlyTimeStamp* ) , Certif icateValues?, RevocationValues?, 

ArchiveTimeStamp* ) > 

< lATTLIST UnsignedSignatureProperties 

Id ID #IMPLIED 
> 

< ! ELEMENT UnsignedDataOb jectProperties (UnsignedDataOb jectProperty*) > 
< lATTLIST UnsignedDataOb jectProperties 

Id ID #IMPLIED 
> 

<! ELEMENT UnsignedDataOb jectProperty (#PCDATA %Any.ANY;)*> 

<! — End SignedSignatureProperties, SignedDataOb jectProperties, 
UnsignedSignatureProperties, UnsignedDataOb jectProperties — > 

<! — Start Qualif yingPropertiesRef erence — > 

<!ELEMENT Qualif yingPropertiesRef erence (Transforms? ) > 
< lATTLIST QualifyingPropertiesReference 

URI CDATA #REQUIRED 

Id ID #IMPLIED 
> 

<! — End QualifyingPropertiesReference — > 

<! — End container types — > 

<! — Start SigningTime — > 

<! ELEMENT SigningTime (#PCDATA)> 

<! — End SigningTime — > 
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<! — Start SigningCertif icate — > 

<!ELEMENT SigningCertif icate (Cert+)> 
<!ELEMENT Cert (CertDigest, IssuerSerial) > 
<!ATTLIST Cert 

URI CDATA #IMPLIED 
> 

<! ELEMENT CertDigest (DigestMethod, DigestValue) > 
<!ELEMENT IssuerSerial (X509lssuerNaine, X509SerialNumber ) > 
<!ELEMENT X509IssuerNaine (#PCDATA)> 
<! ELEMENT X50 9SerialNumber (#PCDATA)> 

<! — End SigningCertif icate — > 

<! — Start SignaturePolicyldentif ier — > 

<!ELEMENT SignaturePolicyldentif ier (SignaturePolicyld | 

SignaturePolicylmplied) > 

<! ELEMENT SignaturePolicylmplied ANY> 

<!ELEMENT SignaturePolicyld (SigPolicyld, Transforms?, SigPolicyHash, 

SigPolicyQualif iers? ) > 

<!ELEMENT SigPolicyld (Identifier, Description?, DocumentationRef erences? ) > 

<!ELEMENT SigPolicyHash (DigestMethod, DigestValue) > 

<!ELEMENT SigPolicyQualif iers (SigPolicyQualif ier+) > 

<!ELEMENT SigPolicyQualif ier (#PCDATA %Any.ANY; ) *> 

<! — End SignaturePolicyldentif ier — > 

<! — Start SPURT and SPUserNotice — > 

<! ELEMENT SPURT (#PCDATA)> 

<!ELEMENT SPUserNotice (NoticeRef?, ExplicitText?) > 

<!ELEMENT NoticeRef (Organization, NoticeNumbers ) > 

<!ELEMENT ExplicitText (#PCDATA)> 

<!ELEMENT Organization (#PCDATA)> 

<!ELEMENT NoticeNumbers (int*)> 

<! ELEMENT int (#PCDATA)> 

<! — End SPURT and SPUserNotice — > 

<! — Start Countersignature — > 

<! ELEMENT Countersignature (Signature) > 

<! — End Countersignature — > 

<! — Start DataObjectFormat — > 

<!ELEMENT DataObjectFormat (Description?, Ob jectTdentif ier?, MimeType?, 

Encoding? ) > 

<!ATTLTST DataObjectFormat 

ObjectReference CDATA #REQUIRED 
> 

<! ELEMENT MimeType (#PCDATA)> 
<! ELEMENT Encoding (#PCDATA)> 

<! — End DataObjectFormat — > 

<! — Start CommitmentTypelndication — > 

<! ELEMENT CommitmentTypelndication (CommitmentTypeTd, (ObjectReference* | 

AllSignedDataOb jects ) , CommitmentTypeQualif iers?) > 

<!ELEMENT CommitmentTypeTd (Identifier, Description?, 

DocumentationRef erences? ) > 

<!ELEMENT ObjectReference (#PCDATA)> 

<!ELEMENT AllSignedDataOb jects ANY> 

<!ELEMENT CommitmentTypeQualif iers (CommitmentTypeQualif ier* ) > 

<! ELEMENT CommitmentTypeQualif ier (#PCDATA %Any.ANY; ) *> 

<! — End CommitmentTypelndication — > 
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<! — Start SignatureProductionPlace — > 

<!ELEMENT SignatureProductionPlace (City?, StateOrProvince?, PostalCode?, 

Count ryName ? ) > 

<!ELEMENT City (#PCDATA)> 

<!ELEMENT StateOrProvince (#PCDATA)> 

<!ELEMENT PostalCode (#PCDATA)> 

<! ELEMENT CountryName (#PCDATA)> 

<! — End SignatureProductionPlace — > 

<! — Start SignerRole — > 

< [ELEMENT SignerRole (ClaimedRoles?, Certif iedRoles?) > 

<!ELEMENT ClaimedRoles (ClaiinedRole + ) > 

<!ELEMENT Cert if iedRoles (Certif iedRole+) > 

<!ELEMENT ClaimedRole (#PCDATA %Any.ANY; ) *> 

<! ELEMENT Cert if iedRole (#PCDATA)> 

<!ATTLIST Certif iedRole 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 

<! — End SignerRole — > 

<! — Start AllDataOb jectsTimeStamp, IndividualDataOb jectsTimeStamp, 
SignatureTimeStamp — > 

<!ELEMENT AllDataOb JectsTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
< lATTLIST AllDataOb jectsTimeStamp 

Id ID #IMPLIED 
> 

<! ELEMENT IndividualDataOb JectsTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
< lATTLIST IndividualDataOb jectsTimeStamp 

Id ID #IMPLIED 
> 

<! ELEMENT SignatureTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
< lATTLIST SignatureTimeStamp 

Id ID #IMPLIED 
> 

<1 — End AllDataOb jectsTimeStamp, IndividualDataOb jectsTimeStamp, 
SignatureTimeStamp — > 

<1 — Start CompleteCertif icateRef s — > 

<1ELEMENT CompleteCertif icateRef s (CertRefs)> 
< lATTLIST CompleteCertif icateRef s 

Id ID #IMPLIED 
> 
<1 ELEMENT CertRefs (Cert+) > 

<1 — End CompleteCertif icateRef s — > 

<1 — Start AttributeCertif icateRef s — > 

<1ELEMENT AttributeCertif icateRef s (CertRefs) > 
< lATTLIST AttributeCertif icateRef s 

Id ID #IMPLIED 
> 

<1 — End AttributeCertif icateRef s — > 

<1 — Start CompleteRevocationRef s — > 
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<!ELEMENT CompleteRevocationRef s (CRLRefs?, OCSPRefs?, OtherRefs?)> ~ " 

<!ATTLIST CompleteRevocationRef s 

Id ID #IMPLIED 
> 

<! ELEMENT CRLRefs (CRLRef+)> 
<! ELEMENT OCSPRefs (OCSPRef+)> 
<! ELEMENT OtherRefs (OtherRef+) > 

<!ELEMENT CRLRef (DigestAlgAndValue, CRLIdentif ier? ) > 
<!ELEMENT OCSPRef (OCSPIdent if ier , DigestAlgAndValue? ) > 
<!ELEMENT OtherRef (#PCDATA %Any.ANY; ) *> 

<! ELEMENT DigestAlgAndValue (DigestMethod, DigestValue) > 
<!ELEMENT CRLIdentif ier (Issuer, IssueTime, Number?) > 
<!ATTLIST CRLIdentif ier 

URI CDATA #IMPLIED 
> 

<!ELEMENT OCSP Identifier (ResponderlD, ProducedAt)> 
<!ATTLIST OCSPIdentifier 

URI CDATA #IMPLIED 
> 

<! ELEMENT Issuer (#PCDATA)> 
<! ELEMENT IssueTime (#PCDATA)> 
<! ELEMENT Number (#PCDATA) > 
<!ELEMENT ResponderlD (#PCDATA)> 
<! ELEMENT ProducedAt (#PCDATA)> 

<! — End CompleteRevocationRef s — > 

<! — Start AttributeRevocationRef s — > 

< [ELEMENT AttributeRevocat ionRef s (CRLRefs?, OCSPRefs?, OtherRefs?) > 
< lATTLIST AttributeRevocationRef s 

Id ID #IMPLIED 
> 

<! — End AttributeRevocationRef s — > 

<! — Start SigAndRef sTimeStamp, Ref sOnlyTimeStamp — > 

<! ELEMENT SigAndRef sTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
< lATTLIST SigAndRef STimeStamp 

Id ID #IMPLIED 
> 

<!ELEMENT Ref sOnlyTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
< lATTLIST Ref SOnlyTimeStamp 

Id ID #IMPLIED 
> 

<! — End SigAndRef STimeStamp, Ref sOnlyTimeStamp — > 

<! — Start Certif icateValues — > 

<!ELEMENT Cert if icateValues (EncapsulatedX509Certif icate | 

OtherCertif icate) *> 

< lATTLIST Certif icateValues 

Id ID #IMPLIED 
> 

<!ELEMENT EncapsulatedX509Certif icate (#PCDATA)> 
< lATTLIST EncapsulatedX509Certif icate 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 
<! ELEMENT OtherCertif icate (#PCDATA %Any.ANY;)*> 

<! — End Certif icateValues — > 
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<! — Start RevocationValues — > 

<!ELEMENT RevocationValues (CRLValues?, OCSPValues?, OtherValues?) > 
<!ATTLIST RevocationValues 

Id ID #IMPLIED 
> 

<! ELEMENT CRLValues (EncapsulatedCRLValue+) > 
<! ELEMENT OCSPValues (EncapsulatedOCSPValue+) > 
<!ELEMENT OtherValues (OtherValue+) > 

<! ELEMENT EncapsulatedCRLValue (#PCDATA)> 
<!ATTLIST EncapsulatedCRLValue 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 

<! ELEMENT EncapsulatedOCSPValue (#PCDATA)> 
<!ATTLIST EncapsulatedOCSPValue 

Id ID #IMPLIED 

Encoding CDATA #IMPLIED 
> 
<! ELEMENT OtherValue (#PCDATA %Any.ANY; ) *> 

<! — End RevocationValues — > 

<! — Start ArchiveTimeStamp — > 

<! ELEMENT ArchiveTimeStamp (Include+, CanonicalizationMethod?, 
(EncapsulatedTimeStamp | XMLTimeStamp) ) > 
<!ATTLIST TimeStamp 

Id ID #IMPLIED 
> 

<! — End ArchiveTimeStamp — > 
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Annex E (informative): 
Incorporation of qualifying properties 

As stated in the normative part of the present document, new elements have been defined to incorporate properties (both 
signed and unsigned) that qualify the whole signature, the signer or individual signed data objects: 

Qualif yingProperties, SignedProperties, UnsignedProperties, 

SignedSignatureP roper ties, UnsignedSignatureP roper ties, SignedDataObject Proper ties 

and UnsignedDataProperties. 

Annex E shows an example of direct incorporation of qualifying properties and one example of indirect incorporation of 
these properties. 

Below follows the resulting general structure of direct incorporation: 

<ds : Signature ID?> 

<ds : Signedinf o> 

<ds : Canonical iz at ionMet hod/ > 
<ds : SignatureMethod/> 
(<ds : Reference URI? > 
(<ds : Transf orms>) ? 
<ds : DigestMethod> 
<ds : DigestValue> 
</Ref erence>) + 
</ds : Signedinf o> 

<ds : SignatureValue> 

(<ds :KeyInfo>) ? 

<ds :Object> 

<Qualif yingProperties> 

<SignedProperties> 

<SignedSignatureProperties> 

<! — Collection of signed XML elements with 

properties qualifying the signature or the 

signer — > 
</SignedSignatureProperties> 

<SignedDataOb ject Proper ties > 

<! — Collection of signed XML elements with 

properties individually qualifying signed data 

objects — > 
</SignedDataOb jectPropertiesSigned> 

</SignedProperties> 

<UnsignedProperties> 

</UnsignedSignatureProperties> 

<! — Collection of unsigned XML elements with 

properties qualifying signature or signer — > 
</UnsignedSignatureProperties> 

<UnSignedDataOb ject Proper ties > 

<! — Collection of unsigned XML elements with 
properties individually qualifying signed 
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data objects — > 
</UnSignedDataOb ject Proper ties > 

</UnsignedProperties> 

</Qualif yingProperties> 

</ds :Object> 

</ds : Signature> 

Below follows an example showing the inclusion of three sets of qualifying properties: 

• The first one includes signed properties qualifying the signature, namely: 

the time of signature production (element SigningTime); 

a restricted set of references to certificates to be used in verifying a signature. This also includes a 
reference to the certificate containing the public key corresponding to the private key used in the 
signature computation (element SigningCertif icate); 

an identification of the signature policy under which the signature has been produced and will have to be 
verified (element SignaturePolicyldentif ier). 

• The second one includes signed properties qualifying the signed data object, namely: 

a time-stamp of the signed data object, proving that the content has been produced before the time 
indicated in the time-stamp (element AllDataOb jectsTimeStamp); 

an indication of the format of the signed object (element DataOb jectFormat). 

• The third one includes unsigned properties qualifying the signature, namely: 

a time-stamp on the electronic signature itself, proving that the signature was produced before the time 
indicated by such time-stamp (element SignatureTimeStamp); 

the references to the full set of CA certificates that the verifier of the electronic signature has used to 
validate the electronic signature (element CompleteCertif icateRef s); 

the references to the revocation material (CRLs or OCSP responses) used in the validation of the signer 
and CA certificates used the full to validate the electronic signature (element 

CompleteRevocationRef s); 

the time-stamp generated over the electronic signature with the aforementioned qualifying information 
(element SigAndRef sTimeStamp); 

the full set of CA certificates that the verifier of the electronic signature has used to validate the 
electronic signature (element Certif icateValues); 

the revocation material (CRLs or OCSP responses) used in the validation of the signer and CA 
certificates used the full to validate the electronic signature (element RevocationValues). 

[ sOl ] <ds : Signature Id=" Signature Id" 
xmlns :ds="http: //www.w3 . org/2000 /0 9/xmldsig#> 
[s02] <ds :SignedInfo Id="SignedInf oId"> 

[s03] <ds : Canonical iz at ionMet hod Algorithm="http : //www.w3 . org/TR/2001/REC- 
xml-cl4n-20010315" /> 
[s04] <ds :SignatureMethod 

Algorithm="http: //www . w3 . org/2000 /O 9/xmldsig#dsa-shal " /> 
[sOS] <ds : Reference URI=" http : //www . etsi . org /docToBe Signed " 
Id="FirstSignedDocument "> 
[s06] <ds :DigestMethod 
Algorithm="http: //www . w3 . org/2000 /0 9/xmldsig#shal " /> 

[s07] <ds :DigestValue> </ds : DigestValue> 

[s08] </ds : Reference> 
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[s09] <ds : Reference URI="#SignedPropertiesId" 
Type="http: //uri . et si . org/01 903/ vl .2 . 2#SignedProperties "> 
[slO] <ds :DigestMethod 
Algorithin="http: //www . w3 . org/2000 /O 9/xinldsig#shal "/> 

[sll] <ds :DigestValue> </ds : DigestValue> 

[sl2] </ds : Ref erence> 
[sl3] </ds:SignedInfo> 

[sl4] <ds : SignatureValue Id="SignatureValueId"> </ds : SignatureValue> 

[sl5] <ds:KeyInfo> </ds : Keyinf o> 

[sl6] <ds:Object > 

[sl7] <Qualif yingProperties Id="Qualif yingPropertiesId" 
Target = "#SignatureId" xmlns = "http : //uri . et si . org/01 903/ vl .2 .2#" 
xmlns:ds="http: //www . w3 . org/2000 /0 9/xmldsig#"> 

[sl8] <SignedProperties Id="SignedPropertiesId"> 
[sl9] <SignedSignatureProperties > 

[s20] <SigningTime> </SigningTime> 

[s21] <SigningCertif icate> </signingCertif icate > 

[s22] <SignaturePolicyIdentif ier> </ SignaturePolicyldentif ier > 

[ s2 3] </SignedSignatureProperties> 
[s24] <SignedDataOb jectProperties> 

[s25] <DataOb jectFormat> </DataOb jectFormat> 

[s26] <AllDataObjectsTimeStamp Id="AllDataOb jectsTiineStampId"> 

</AllDataOb jectsTiineStamp> 

[s27] </SignedD at aObject Proper ties> 

[s28] </SignedProperties> 

[s29] <UnsignedProperties > 

[ s30 ] <UnsignedSignatureProperties> 

[s31] <SignatureTimeStamp 

Id="SignatureTimeStampId"> </SignatureTimeStamp> 

[s32] <CompleteCertif icateRef s Id="CompleteCertif icateRef sld"> 

...</CompleteCertif icateRef s> 

[s33] <CoinpleteRevocationRef s 

Id="CoinpleteRevocationRef sld"> </CompleteRevocationRef s> 

[s34] <SigAndRefsTiineStamp 

Id="SigAndRefsTimeStampId"> </SigAndRef sTimeStamp> 

[s35] <Certif icateValues 

Id="CertificateValuesId"> </Certif icateValues> 

[s36] <RevocationValues 

Id="RevocationValuesId"> </RevocationValues> 

[ s37 ] </UnsignedSignatureProperties> 
[s38] </UnsignedProperties> 
[s39] </Qualif yingProperties> 
[s40] </ds:Object> 
[s41] </ds : Signature> 

[sOl] Beginning of the XML signature. The namespace by default is the namespace defined in XML-DIGSIG. 

[s02]-[sl3] The ds : Signedinf o element contains the information that is actually signed. 

[s03] The ds : CanonicalizationMethod element indicates the algorithm used to get a canonical representation 
of the Signedlnfo element before being signed. 

[s04] The ds : SignatureMethod indicates the algorithms used to sign Signedlnfo. 

[s05] to [sl6] ds : Reference elements contain the digest value and indication on the digest algorithm for each data 
object that has to be (indirectly) signed. Each one also has a reference to the corresponding data object. These elements 
also have the Id attribute that can be used to make individual references each one of them. 

[s05-s08] The first ds : Reference element. Its URI attribute references the data object that has to be signed. 

ds : DigestMethod indicates the digest algorithm (shal in this case) and ds : DigestValue contains the digest 

value filtered in base 64. 
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[s09-sl2] The second ds : Reference element. Its URI attribute points to the SignedProperties element (using 
the URI attribute) that contains the whole set of signed properties, ds : DigestMethod indicates the digest algorithm 
(shal in this case) and ds : DigestValue contains the digest value filtered in base. This means that the digest value 
of that SignedProperties is included in Signedinf o and in consequence signed when this element is signed. 
The ds : Type attribute indicates that this element is a reference to the SignatureProperties element as mandated in 
clause 6.3.1. 

[sl4] ds : SignatureValue contains the computed digital signature of ds : Signedinf o in base 64. 

[sl5] ds : Keyinf o contains cryptographic material to verify the signature. 

[sl6-s40] ds : Object contains three elements with the properties qualifying both the signature and the signed data 
object. 

[sl7-39] Qualif yingProperties contains the full set of qualifying properties both signed 
(SignedProperties) and unsigned (UnsignedProperties). The namespace by default is changed for this 
element and its contents to the one defined as namespace by default in the schema definition given in the present 
document in order not to have to qualify the whole set of elements. Additionally, as elements already defined in [3] are 
used in the definitions, its namespace is also defined (prefix ds). 

[sl8-s28] SignedProperties contains the whole set of qualifying properties that are signed grouped in two 
sequences. The first one (SignedSignatureProperties) contains all the signed properties that qualify the 
signature. The second one (SignedDataOb jectProperties) contains all the signed properties that individually 
qualify each signed data object. 

[sl9-ss23] SignedSignatureProperties contains all the signed properties that qualify the signature 

(SigningTime, SigningCertif icate, SignaturePolicyldentif ier ) . 

[s20] SigningTime contains the value of the signing instant when the signature has been computed. 

[s21] SigningCertif icate contains, as stated above, a restricted set of references to certificates to be used in 
verifying a signature. 

[s24-27] SignedDataOb jectProperties contains all the signed properties that individually qualify each signed 
data object (AllDataOb jectsTimeStamp, DataOb jectFormat). 

[s25] DataOb jectFormat identifies the format of the signed data object. 

[s26] AllDataOb jectsTimeStamp is a time-stamp issued for the signed data object. 

[s29-38] UnsignedProperties contains the whole set of qualifying properties that are NOT signed 

[s30-s37] UnsignedSignatureProperties the whole set of unsigned properties that qualify the signature. 

[s31] SignatureTimeStamp contains a time-stamp for the signature itself. 

[s32] CompleteCertif icateRef s contains references to CA certificates in the certification path used to verify the 
signature. 

[s33] CompleteRevocationRef s contains references to revocation information used to verify the signature. 

[s34] SigAndRef sTimeStamp contains a time-stamp over the XAdES-C form of the electronic signature. 

[s35] Certif icateValues contains the values of the certificates referenced in CompleteCertif icateRef s. 

[s36] RevocationValues contains the revocation data used to validate the electronic signature. 

NOTE: The tree shown in the example above does not explicitly show certain optional XML elements (like 
ds : Transforms For a complete description of this tree see XML-Signature Core Syntax and 
Processing [3]. 
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Below will follow the example of indirect incorporation of all the unsigned properties. In this example, the signed 
properties will be directly incorporated into the ds : Signature element as in the previous example. However, the 
unsigned properties will be separately stored in other place. To incorporate these properties use is made of the 
QualifyingPropertiesReference element pointing to the element containing them. 

Below follows the contents of the XAdES itself that could be located, for instance, at the URI 
http://uri.etsi.Org/01903/vl.2.2/Indirect-Incorporation/Signature2 : 



[sOl] <ds : Signature Id="Signature2Id" 

xmlns : ds="http : //www . w3 . org/2000/0 9/xmldsig#> 

[s02] <ds :SignedInfo Id="SignedInf oId"> 

[s03] <ds : CanonicalizationMethod 
Algorithin="http: //www . w3 . org/TR/2001/REC-xml-cl4n-20010315" /> 
[s04] <ds : SignatureMethod 

Algorithm="http: //www.w3 . org/2000 /O 9/xmldsig#dsa-shal " /> 
[s05] <ds : Reference URI=" http : //www . etsi . org/docToBe Signed " 
Id="FirstSignedDocument "> 
[s06] <ds :DigestMethod 
Algorithin="http: //www . w3 . org/2000 /O 9/xinldsig#shal "/> 

[s07] <ds :DigestValue> </ds : DigestValue> 

[s08] </ds : Reference> 

[s09] <ds :Reference URI="#SignedPropertiesId" 
T Yp e = http ://uri.etsi.org/01903/vl.2. 2#SignedProperties > 
[slO] <ds :DigestMethod 
Algorithin="http: //www . w3 . org/2000 /O 9/xinldsig#shal " /> 

[sll] <ds :DigestValue> </ds :DigestValue> 

[sl2] </ds : Ref erence> 
[sl3] </ds :SignedInfo> 

[sl4] <ds : SignatureValue Id="SignatureValueId"> </ds : SignatureValue> 

[sl5] <ds:KeyInfo> </ds : Keyinf o> 

[sl6] <ds:Object > 

[sl7] <Qualif yingProperties Id="Qualif yingProperties " 

Target = "#SignatureId" xmlns = "http: //uri . etsi . org/0 1903/ vl .2 .2#" 

xmlns :ds="http: //www . w3 . org/2000 /0 9/xmldsig#"> 

[sl8] <SignedProperties Id="SignedPropertiesId"> 

[sl9] <SignedSignatureProperties > 

[s20] <SigningTime> </SigningTime> 

[s21] <SigningCertif icate> </SigningCertif icate > 

[s22] <SignaturePolicYldentif ier> </SignaturePolicyIdentif ier > 

[s23] </SignedSignatureProperties> 
[s24] <SignedDataOb ject Proper ties > 

[s25] <DataOb jectFormat> </DataOb jectFormat> 

[s26] <AllDataObjectsTimeStamp Id="AllDataOb jectsTimeStampId"> 

</AllDataOb jectsTimeStamp> 

[s27] </SignedDataOb jectProperties> 

[s28] </SignedProperties> 

[s29] </Qualif yingProperties> 

[ s30 ] <Qualif yingPropertiesRef erence 
URI="http: //uri. etsi.org/01903/vl .2 . 2 /Indirect - 
Incorporation/examplel#Qualif yingProperties Id" > 

[s31] <ds : Transf orms> </ds : Transf orms> 

[ s32 ] </Qualif yingPropertiesRef erence> 
[s33] </ds:Object> 
[s34 ] </ds : Signature> 



[sl-s29] These lines are the same as in the first example. They show how the signed properties are directly incorporated. 

[s30-s32] These lines show how to indirectly incorporate the unsigned properties stored in other place using the 

QualifyingPropertiesReference element. 

[s30] The URI attribute contains the URI pointing to the QualifyingProperties element that contains those 
qualifying properties that are being indirectly incorporated. In this case, it points to a file that could be found in 
http://uri.etsi.Org/01903/vl.2.2/Indirect-Incorporation/examplel , which contains this element. 
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[s31] The ds : Transforms element contains the whole set of transformations to compute on the file where the 
unsigned properties are stored. 

This example ends showing that part of the file that could be found in 
http://uri.etsi.or.g/01903/vl.2.2/Indirect-Incorporation/examplel that contains the Qualif yingProperties element 

referenced in the Qualif yingPropertiesReference . 

<! — This is the part of the file found in 

http://uri.etsi.org/01903/vl. 2. 2 /Indirect -Incorporation /example 1 that 
contains the Qualif yingProperties element containing the unsigned properties 
that are indirectly incorporated in the advanced electronic signature — > 

[si] <Qualif yingProperties Id="Qualif yingPropertiesId" 

Target="http://uri. etsi.org/01903/vl. 2. 2/ 

Indirect -Incorpor at ion /Signature2#Signature2 Id" 

xmlns="http: //uri . etsi . org/01903/vl . 2 . 2#" 

xmlns:ds="http: //www . w3 . org/2000 /0 9/xmldsig#"> 

[si+1] <UnsignedProperties > 

[ si+2 ] <UnsignedSignatureProperties> 

[si+3] <SignatureTimeStamp 

Id="SignatureTimeStampId"> </SignatureTimeStamp> 

[si + 4] <CompleteCertif icateRef s Id="CompleteCertif IcateRef sld"> 

...</CompleteCertif IcateRef s> 

[si+5] <CompleteRevocationRef s 

Id="CompleteRevocationRef sld"> </CompleteRevocationRef s> 

[si + 6] OigAndRef sTimeStamp 

Id="SigAndRef sTimeStampId"> </SigAndRef sTimeStamp> 

[si+7] <Certif icateValues 

Id="Certif icateValuesId"> </Certif icateValues> 

[si+8] <RevocationValues 

Id="RevocationValuesId"> </RevocationValues> 

[ si + 9] </UnsignedSignatureProperties> 
[si+10] </UnsignedProperties> 
[si+11] </Qualif yingProperties> 

<! — Below would follow the rest of the file — > 

In the example above the QualifyingProperties element is shown that is part of the file that could be found in 
http://uri.etsi.Org/01903/vl.2.2/Indirect-Incorporation/examplel and that is pointed by the URI element in the 
Qualif yingPropertiesReference in the advanced electronic signature. 
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